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MINIMIZING THE NAMING FACILITIES REQUIRING PROTECTION 
IN A COMPUTING UTILITY* 

by 

Richard Glenn Bratt 



ABSTRACT 



This thesis examines the various neehaniaitts for naming 
the information objects stored in a ffen*riO.»ptorpo»e computing 
utility, and isolates a basic, set of naming facilities that must 
be protected to assure complete, control ©v»r «*•* interaction and 
that allow desired interactions among users to occur in a natural 
way. Minimizing the protected naming Nf*oilitl«4 consistent with 
the functional objective of controlled, but natural, user 
interaction contributes to defining a security kernel for a 
general-purpose computing utility. $ he security kernel Is that 
complex of programs that must be correct if control on user 
interaction is to be assured. 

The Multics system is used a* a test case, and its 
segment naming mechanisms are redesigned to reduce the part that 
must be protected as part of the a**p*r»is©r. To show that tals 
smaller protected naming facility can still support the complete 
functionality of Multics, a test implementation of the design is 
performed. The new design is shown #a chave ^significant impact 
on the size and complexity of the Multics supervisor. 



•This report is based upon a thesis of the same title submitted 
to the Department of Electrical Engineering r Massachusetts 
Institute of Technology, on July 7, 1975 -in partial fulfillment 
of the requirements for the degree of Master of Science. 
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Introduction 
1-1 Brief Statement of the Problem ^ RmU . 

This thesis investigates the class of computing utility 
mechanisms that deal with naming information objects within a 
computing utility. Our goal is to understand the various 
functions played by name spaces in contemporary computing 

i 

utilities and to decide which of these functions must be 
protected to assure complete control over user interaction, the 
Multics system, which is a sophisticated computing utility, will 
be used to test the validity of our conclusions. (1) We will 
find that Multics protects several mechanisms that we claim need 
not be protected to assure control ovarusar interaction. To 
substantiate our claim we will present a r*d*si*gn of Multics that 
allows these mechanisms to be unprotected without sacrificing the 
ability to control. user interaction. The resulting reduction in 
the amount of code that must be protected to assure control over 
user interaction contributes to defining a security kernel for 
Multics. 



(1) The Multics system was developed as a prototype computing 
utility by Honeywell Information Systems, inc. , and M.I.T. 's 
Project MAC. A complete bibliography of the Multics system may 
be found in [M2]. 
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1.2 Related Merit 

The Multics system [C1, C2, M2, 01, S3] is an example 
of a sophisticated state-of-the-art computing - utility. As part 
of a general investigation into how ©ne goes about the task of 
certifying the aeeurity ©f large system* , the Computer Systems 
Research Division of Project MAC at M.I.f, is attempting to 
produce a certifiably secure version ©f the Multics system, by 
redesigning Multics to minimize the collection of programs that 
must be correct to assure complete control over user 
interactions. As a result f this collection of programs, the 
Multics security kernel * has been steadily decreasing in size and 
complexity* A recent masters thesis CI!} describes how a Multics 
security kernel that does not include a dynamic linking mechanism 
was developed* This thesis reports the results of another effort 
to reduce the siae of the Multics security kernel. 

1.3 Background 

A computing utility is any computer system, or network 
of interconnected computing systems, that provide general 
computing services to a community of users. Among the most 
important services provided by computing utilities are facilities 
that allow users to share, store, retrieve, and process 
information. To facilitate the manipulation and sharing of 
stored information, computing utilities must support a multitude 



-8- 



of name spaces. These name spaoes, which maintain a 
correspondence between a collection of names and the information 
they denote, provide organization of the collections of 
information processed in the system. 

We find many name spaces at all hwels at a computing 
utility. The base computers on wthioh a computing utility runs 
implicitly employ a name space that maps m , «©& , of integer names 
(actually a set of representations, of integftrst ©ailed addresses 
into a set of words of computer memory. Similar lyy direct access 
mass storage devices such as magnetic disks aftd drums define a 
name space that maps physical storage addresses- into records of 
bits. At a higher level, most oomp.j*fc#f» utA114A«s support a name 
space that allows its users to denote files of information by 
character string names such as n John's__file". Detailed analysis 
of most systems reveals many other examples rof name spaces. 

We have stated that a competing utility provides 
information processing, services to a community j of users. Since 
we have not placed any restrictions upon the esmposltion of this 
user community, we must assume that these users harbor ill will 
toward each other or toward the computing utility itself . This 
ill will can manifest itself in an jf of three ways. A malicious 
user might attempt to use, modify, or prevent others from using 
or modifying information in the computing utility. Even in a 
computing utility shared by a non-malicious user community, one 
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user might aeetdently compromise another* user's information or 4 
computation. 

Any general computing utility must prevent such 
undesirable interact ions between its users. To this end it must 
secure its users against unauthorised use-, modification, or 
denial of use of the information 1 they orocess in the computing 
utility, this requires that the computing utility implement an 
authorization mechanism that allows those user-information 
interactions that are to be permitted to be specified. The 
information supplied to the system through this authorization 
mechanism must then be used by an access oohtrol mechanism that 
intercepts all user-lnforaatien Interactions and verifies that 
they are authorized. 

The presence of access authorization and control 
mechanisms in a computing utility does not prima facie secure its 
users from harmful, uncontrolled interactions with other users of 
the computing utility. it must be established that these 
protection mechanisms do indeed perform their intended task 
without error* It further must fee established that these 
information protection mechanisms cannot be subverted, damaged, 
or circumvented. Only then may users of the computing utility 
process sensitive, irreplaceable* or timely information with 
reasonable freedom from fear for its security. 
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We identify that subset of the mechanisms of a 
computing utility which must be correct in order to guarantee 
the security of the information contained in the oomputing 
utility as its security kernel. 

Clearly the task of establishing the correctness of the 
security kernel of a computing utility must increase 
monotonically with its size and complexity. For this reason it 
would be advantageous to know which computing utility mechanisms 
need be included in the security kernel for intrinsic reasons. A 
mechanism has an intrinsic need to be included in the security 
kernel of a computing system if and only if lit can be used by one 
computation to influence another computation. The access 
authorization and control mechanisms of a computing utility are 
the two most obvious examples of mechanisms that must be included 
in a security kernel. If a computing utility supports a shared 
name space for identifying stored information, then this 
mechanism, by virtue of its commonality, als*> allows one 
computation to influence another and hence must be considered 
part of the security kernel of the computing utility* 

Mechanisms that have no intrinsic need to be protected 
often are included in the security kernel of a system. Common 
reasons for incorporating a mechanism in the security kernel of a 
computing utility when it has no intrinsic need to be protected 
include the desire to protect the mechanism from damage, the 



-11- 



desire to minimise cross domain 6all» f *nd the need to protect 
the meohaniaa beoause *o««'geoarifeflt»*iiei;««ehiBi»» happens to 
depend upon its- eorraot^ opermtieii^ *>*&#* motivation behind 
including a mechanism in the s*ea*iiy 'kernel of a computing 
utility when it has no security-related need to be protected must 
be carefully analysed r a* the i»cls#ion of the meohanism in the 
security kernel contributes to the complexity of the security 
kernel. Removing the m« a nanism f ro« tls»*<M Purity kernel would 
have the advantage of lessening^ W*e task of establishing the 
correctness of the aaourity kernel, mis thesis will evaluate 
the need forsa«h of the ma^or name -'mprnma Supported by a typical 
computing utility to be included in it###flN»rify kernel; We will 
use the knowledge tfttts aceumulatea t# f aimpiify the Multics 
security kernels - 

1*4 Plan of thesis 

In Chapter II we present a model of a computing 
utility. This< motel pays particular attention to those 
mechanisms that are involved in naming information stored in a 
computing utility. He begin by defining a very simple 
information storage and protection model. Through successive 
enhancement of this model we arrive at a model that we feel 
represents the essence of name space management in a contemporary 
computing utility. As we add each new name space to our model, 
we consider its basic raison >d*Stre, the advantages and 
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disadvantages it provides over the previous model, and most 
importantly its impact upon which hame J spaces in the model must 
be protected as a part of the security kernel. 

Chapter III begins bur ease study of name space 
management in Multics. We identify the major name spaces 
maintained by Multics that, deal with naming stored information 
and establish a correspondence between these name spaces and the 
name spaces of our model. Having established this 
correspondence, we attempt to verify that only the naming 
functions identified in our model as security 1 sensitive are 
implemented by the Multics security kernef. This investigation 
reveals that the Multics reference name spade, a name space used 
in resolving inter-procedure references! lis implemented in the 
Multics security kernel although it has no intrinsic need to be 
protected. (1) The reasons behind this fla^^n the modularity of 
the Multics system are investigated. 

In Chapter IV we develop a design that removes 
reference name management from the security kernel of the Multics 
system. In so doing, we also remove several functions related 
to the management of the Multics global naming hierarchy from the 
Multics security kernel. The most notable of these are that 
function which allows the security kernel to name segments by 



(1) The research" reported in this thesis is based upon the M.I.T, 
Multics system of December 197*1, Multics system 24.2. 
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hierarchy pathnames and that, funcfc ion which allows multiple 
paths in the $vl%ip9,.ptj&§&t, ; $f0eQ~ l fc$.^.w$by t© designate the 
same object. In the course of removing these functions from the 
security kernel, our design drastically changes the Multics 
security kernel in|#r face. Finally, ,|Hr, discafs the impact of 
this design upon the security kernel. 

Chapter V discusses the implications of ©uf security 
kernel design upon code running outside of-sfehe Maltics security 
kernel. We discuss the principle! involved in designing a 
reference name manager which runs o*itsi<t© of, , the. Multics security 
Kernel. In the course of tfeia, ^fet^fei|%|K)*- we uncover an 
important consideration, in »ovin# t JM^dft0diiile 0«t ©f the Multics 
security kernel. Specifically , t> ■4ft£MM!*'t stowrity kernel 
procedures are guaranteed to run >.,v,fc& ;op^l#$&on once invoked. 
This allows them to make assumptions ? ^hat wou^dl Im invalid were 
they to be executed in the inteeup4^|Jt>le environment outside of 
the security kernel. Following this discussion, we show how the 
functions of , pathnjype respjUitiipn, a#d storage system link 
processing may be implemented outside pi '<., feh# Multics security 
kernel. Finally, we dl-scus^, tfee ne#4 for #ipplating the old 
security kernel interface. 

In Chapter VI we v discuss^ the results of a test 
implementation of the security kernel we have designed. This 
test implementation allowed us to measure of the impact of our 
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design upon the complexity and performance of the Multics system. 
We report this data along with a description of our test 
implementation. 

We have included nine appendices in this thesis. 
Appendix A details the structure of the data base for the Multics 
24.2 address space manager and reference name manager. Appendix 
B shows the impact of our design upon the structure and content 
of this data base. Appendix C summarizes the new address space 
manager interface proposed in this thesis. In appendix D we 
present an example of the use of this new interface. Appendix E 
summarizes the impaot of this thesis upon the size of the Multics 
security kernel. In appendix F we report the details and results 
of our performance comparison between Multics system 24.2 'and our 
test system. Appendix G summarizes the effect of our thesis upon 
the complexity of the Multics security kernel interface. 
Appendix H presents the programs of our redesigned address space 
manager for the reader's perusal. Appendix I discusses several 
functions supported by the Multics system 24.2 address space 
manager that, for the sake of simplicity, were not considered in 
the body of the thesis. 
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Name Space Management In a Computing utility 

In this chapter we will develop a model of a computing 
utility. Our emphasis will be upon the roles played by name 
spaces in contemporary computing utilities* Ihia model will be 
developed by adding successive layers to a central model of 
information storage and protection. After we add each successive 
mechanism or name space to this model, we will present a graphic 
representation of the current state of the model. Each node in 
these illustrations will represent a class of names. The name 
space binding one group of names to another group of objects or 
names will be represented by an undirected line. If a name space 
must be protected to control user interaction, then the line 
representing it will be constructed from the symbol '»+" . If the 
name space need not be protected it will be represented by a line 
composed of the symbol ".". 

2.1 ftasift .Information Storage a nd Protection Model 

Some basic notion of information storage and protection 
must be at the heart of any computing utility model. In our 
model the basic vessel of information storage is a segment . In 
theory, we do not restrict the amount of information a segment 
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may contain. In practice, the amount of information a segment 
may hold will be bounded by a combination of hardware and 
software limitations. 

Segments will also serve as our basic unit of 
information protection. We require that s any information 
protection must apply uniformly to all information stored within 
a segment. We will choose an access control list (ACL) based 
information protection scheme for our modes!. The basic 
motivation behind this choice is that Multics, our test case 
system, uses an access control list protection scheme. 

We assume that an access control list is associated 
with every segment. This access control J list encodes the 
authority of each principal in the computing utility to use or 
modify the contents of the associated segment. (1) We will 
further assume that the computing utility supports the necessary 
principal authentication and access atifc«bri*ation mechanisms for 
maintaining the contents of access control lists. We require 
that at some point in referenein^f any s^gtterit, its associated 
access control list be used to mediate 1 that •r>fe>erioe. 



(1) We assume that the reader is familiar with such computer 
science concepts as access, capabilities, domains, processes, and 
principals [S4, F1], 
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2-2 gj-pfrfq, t^hjfepfi ftrif>h#i?d. mm§' 

Me will name a segment and its aeoeas -control, list by a 
name that is unique within the system. This name, which we will 
call a unique identifier fiJID) ,■ will be jsompaet, fixed length, 
and of high information density, f he *niqt»«i#e«Mfier naming a 
segment and its aeoess control M*t will b# assigned when the 
segment is created and may never be changedti ©nee assigned t a 
unique identifier will be\alid f©*?' all *i*«. ■: K we allowed a 
unique identifier to be reused after the segment it names is 
destroyed, then that identifier would not uniquely identify a 
segment. It would be difficult, if not impossible, for a process 
tq distinguish .]a«t1f•«l'-di£^Rfmt':««g|li^•«ia^•t^H^^ at mutually 
exclusive pointy in tine >r named nfey "t&ei -same unique identifier, 
.(1) . - i: ,;.--, " 

It shiOuid be noted that we have purposely excluded the 

possibility of *JWsing more th*n jone ^--imimiejfifcdsefiMfijer bound to 
the same object. The reason f or this; ^ is ^ th# n«mt to determine if 
two segments are identical,. If a*e ^g^ia^anfeeie titsit no two unique 
identifiers are bound to the .same* ojfe,j«o*fe* -toteen- we-' can decide if 
two segments are identical by comparing their unique identifiers. 
Lacking this guarantee, it is not clear how a process could 
decide if two segments were the same segment. (2) 

(1) A discussion of the need for computing systems to support 
unique identifier name spaces may &« fosaad * in Fabry £F1]. 

(2) By equal we mean the lisp concept of eq [M4], 
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Due to their compact size, unique identifiers are well 
suited to efficient implementation and manipulation by computing 
hardware. We will assume, for the moment, that access control 
will operate during the translation of unique identifier to 
object. Certainly this requires that the name spaces that 
associate unique identifiers with objects and their associated 
access control lists be protected. Otherwise • a process could 
circumvent the access control mechanisms of tefee system by causing 
the unique identifier associated with any segment to name an 
arbitrary access control list or eq«*i?alently , causing the unique 
identifier associated with any access control list to name an 
arbitrary segment. It is therefore n*«e*sary that the security 
kernel exercise complete control ovetr the unique identifier to 
access control list and unique identifier to segment name spaces. 
Since the security kernel must force these* two name spaces to 
correspond, we will treat them as a single entity. Figure 2-1 
illustrates this protected binding mapping unique identifiers 
into segments and their access control lists. 

<UID> +++ <SEG/ACL> 
Figure 2-1: Global Machine-Oriented Names 



2-3 Global User Oriented ^ ms 

From the point of view of a human user, the unique 
identifier name space which we have defined for naming segments 
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has four Major* inherent disadvantage*, the first disadvantage is 
tljat humans are poor at dealing with high in format ion density 
names. Second, since unique Identifiers must be assigned by the 
system and not the user, they can have no anea&hie significance. 
Third, the binding or meaning of a unique identifier cannot be 
changed. The final disadvantage in the usage of unique 
identifiers by humans is that it is dft#n convenient to allow 
multiple names in a name space to denote the same object. In our 
model we have pr«elud#d the possibility of having two unique 
identifiers name the same segment. 

For these reasons, any viable computing utility must 
support a user-oriented name space. Ideally this name space 
should bind arbitrary length, «s«t^.smpi>li«fd character string 
names to unique identifiers. In practice, some upper bound is 
often placed upon the size of us«r-supplied names. In any 
reasonable computing utility this restriction must not force 
users to use diff icult»to»re»eiBber non-mnemonic names. To 
promote and encourage information sharing, this name space 
should be sharable by all processes in the computing utility. If 
this were not the case, then one user who wished to share a 
segment with another user would have to communicate the unique 
identifier of that segment to the other user. A shared 
user-oriented name space eases this communieat ion problem by 
allowing users to identify segments in interpersonal 
communication by human-oriented names. 
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A well known weakness of such a staple, unstructured, 
global name space, which results from the nee'd for a name space 
to define a function, is that two users may h%t name different 
segments by the same name. If One user names a segment 
"square_ root_program M , then no other user may u»e this name for 
another segment. Perhaps the most severe 8 manifestation of this 
problem is that a user may not choose a name for a segment 
without knowledge of every name in -.■..the global name space. 

Another consequence of the global scope of the name 
space we are defining is that it provides a path of user 
interaction. One user might intentionally modify a name to 
unique identifier binding that another user was depending upon. 
This constitutes an uncontrolled malieious user interaction since 
it allows one process to cause another process to referenae the 
wrong segment. This in turn may cause an unsuspecting process to 
fail or compromise the integrity or seoui^ity 6f sensitive 
information to which it has access. It is= therefore apparent 
that the ability to change a global user-oriented name space must 
be regulated by the security kernel. 

One simple authorization scheme a computing utility 
could adopt for its global user-oriented name space is to allow 
only the principal who created a name binding to modify that 
binding. Unfortunately, even such a primitive authorization 
mechanism is an unwieldy extension to the unstructured name space 
we have defined. Such an extension would require that every name 
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binding in the name space have an associated principal name used 
to authorize modifications of that name *ln»fi*g. If the name 
space were structured into mz&tngtwl Collections of name 
bindings, then- a more natural authorization scheme based on 
controlling at- proeess' ability to modify aify of a related 
collection of nawe littdings oould be employed'. 

Hierarchical name spaces, such as the user-oriented 
name spaces found in the Hulties [B1, 01} and UNIX [R2] 
time-sharing systems, provide a powerful ««#' natural solution to 
both the naming conflict and authorization problems outlined 
above. Since most name spaces f©mfc* in extemporary computer 
systems, such as the ubiquitous "tws-I#?#l« file- system t«3], may 
be described as degenerate f i*#d*depifr hierarchies , our model 
will support a hierarchical global user-oriented name space. 

Hierarchical name spaces provide their users with a 
powerful organization*! mech*raia». This mechanism encourages 
logically related mam bladings to fc# collected in a single 
directory or directory sub-tree of the hierarchical name space. 
For instance, each user could place name bindings he creates in 
distinct sub-trees of the hierarchy. Naming conflicts within a 
given directory are easily avoided by locally restructuring the 
hierarchical name space so that the conflicting name bindings 
occur in different directories. The directory structure of a 
hierarchical name space can also serve as the basis for a simple, 
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flexible mechanism for controlling the modification of the name 
bindings in the hierarchical name space. Thei ability to use 
and/or change the name bindings in a directory Can be specified 
by an access control list on that dli*ectbVy. Authorization 
control may also be delegated by allowing the access control 
lists of a directory to specify which principal may modify the 
access control lists of its sub-directories. Figure 2-2 extends 
our model to include both human-oriented and machine-oriented 
global name spaces. 

USER ORIENTED MACHINE ORIENTED 
NAMES NAMES 

<PATHNAME> +++++++++++♦+ <0ID> ++++ <SEG/ACL> 
Figure 2-2: Global OSer-Oriented Names 



2.4 Local Machine Oriented Nam*? 

At this point our model provides two very powerful 
mechanisms for naming information. One mechanism allows any 
segment in a computing utility to be denoted by a compact, 
fixed-length, unique identifier. The other naming mechanism 
allows segments to be named by arbitrary length character string 
names indicating the position of a segment in a naming hierarchy. 
In common to both of these mechanisms is the fact that their 
scope is global; they are shared by all users of the computing 
utility. 
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An obvious implication of the soope of a unique 
identifier is that it must be capable of representing as many 
distinct segment 3 aa tike compttfciag, utility caul* create 
throughout ita entire life. Bacattae tha set of segments existing 
at any one time will be a small subset p£ all segments that have 
ever existed or will ever exist-, ©or? m&qm &4e*tMfier name space 
will be sparsely populated. For large apsteos with long 
lifetimes,, this unique identifier name apace .mill also be quite 
large. Economics demand that such large, sparse mappings be 
stored in a compact form requiring more sophisticated accessing 
methods than indexing by ualque identifier valnev This need for 
sophisticated retrieval methods in ooiyapjctl^is with the large 
potential size of the unique identifier to segment mapping tables 
suggests that this name apace is difficult to implement 
efficiently. As a result, contemporary computing hardware 
provides a name space for addressing segments that is much 
smaller and denser than the global unique identifier name space. 
The increased efficiency of representation and; mapping of this 
name space is achieved by restricting the scope of the 
machine-oriented segment identifiers. 

The local machine-oriented name space in our model is 
patterned after the Mult lea segment number name space. Like 
unique identifiers, segment numbers are compact, fixed-length, 
machine-oriented names. Unlike unique identifiers, relatively 
few segment numbers are supported (1) and segment numbers are 
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locally dense so that simple, efficient hardware translation 
techniques can be used. Since segments will be identified to the 
base level of the computing utility by segment number, we will 
call a segment number name space an address space. 

There are many possible choices for the scope of 
segment numbers. A cooperating collection of processes could 
share a common segment number address space. Segment numbers 
could be private to a process, shared by all domains in that 
process. Conversely, the scope of a segment number could be a 
domain. it is even possible to imagine a system in which the 
scope of a segment number is temporally restricted. The choice 
of which of these or other possible schemed for limiting the 
scope of segment numbers is appropriate for a given computing 
utility depends upon both the hardware on which it must run and 
the desired patterns of interaction within the computing utility. 
The larger we allow the scope of a name space to 1 be, the greater 
the cost of translating names in that name space. Conversely, 
the smaller we make the scope of a name space, the fewer the 
naming needs it can satisfy, 

If we desire Tnter-domain communication to be 
efficient, then it would be inappropriate to restrict the scope 
of segment numbers to a domain, were this done, segments could 



ihL!? U i tiOS «.!? Uppor !; S a loca1 ' ^chine-oriented name space of 
about four thousand segment numbers. 



at 
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only be named in inter-domain communication by unique identifier 
or, worse still , pathname. Since these naaes are not directly 
usable by the base level hardware of the c-enpiutifig utility, they 
would have to be mapped by the receiving d^omaAn into its segment 
number address space before the segment named could be 
referenced. By similar reasoning, if inter-fpjrooess communication 
occurs with high frequency in a particular computing t*til ity then 
that computing utility might choosy to share a segment number 
address space among a group of cooperating processes. 

The choice of the scope of segment numbers represents 
an engineering trade-off. We must limit fehe scope of segment 
numbers so that they may be efficiently Implemented in hardware. 
Additionally, the smaller the scope of a segment number the less 
its need to be protected* If an address space is local to a 
protection domain, then it may be ,fre#ly manipulated by that 
domain without compromising security. In opposition to the 
efficiency considerations that weigh in favor of reducing the 
scope of segment numbers is the desire 4h» make the scope of a 
segment number as large as possible so as to make communication 
between different computer systems, processes, domains, and 
moments in time as efficient as possible* The desired 
characteristics and resources available to each computing utility 
must be carefully evaluated to determine the largest group of 
interacting objects that can share an address space without 
making the address space unacceptably large. 
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Routine communication between the ; security kernel 

domain and other protection domains in a computing utility should 

probably, for performance and modular programming reasons, be 

performed by using segment numbers to denote segments. This 

requires that the ability to manipulate tihe segment number name 

space we have just defined be controlled by the security kernel. 

This need for the security kernel to control the manipulation of 

an address space would not arise if address spaces did not span 

protection domains. The reader should take note of the fact that 

since segment numbers do not have global scope, our global 

user-oriented name space fisjaapJt, be implemented by binding names 

to segment numbers. Figure 2-3 extends our model to include the 

protected binding of segment numbers to segments and their aecess 

control lists. We also include, a protected binding between 

segment numbers and unique identifiers. This binding allows the 

identity of a segment named by a segment number to be 

established. 

USER ORIENTED MACHINE ORIENTED 
NAMES NAMES 

PER-SYSTEM <PATHNAME> ♦♦+++♦«.+++ <uid> +♦+ <SEG/ACL> 

+ + 

PER-ADDRESS SPACE <SEGNO> 

Figure 2-3: Local Machine-Oriented Names 
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2.5 uxpjU, ,&ftsfij;lflt<?rg 

Economios require that we refill* the segment number to 
access control list and segment tr^slatim* depicted by our 
model 4. These translations imst be performed #poft every reference 
to a segment* ft is thus essential t**t " -tiiey be efficiently 
implemented* In light of current ic«»p«tlftg technology, these 
translations must be performed ill " tiardswa**e if we desire our 
computing utility to be «ts©noai©ally fNMtslbie* 

Contemporary computing hardware awfrperts neither the 
ability to address arbitrary amounts of »t ©rage nor the ability 
to perform the necessary access eoatnjl lilt search upon every 
reference to a segment. To solve these preMems one frequently 
finds two high-speed, hardware lo®fc**aide memories aiding the 
processors that implement a computing utility* One associative 
memory maps a segment number and domain identifier into a 
hardware interpretable representation of the domain's access to 
the segment specified by that segment number* We will call the 
entries in this associative memory protection descriptors (PDS). 
The other associative memory maps a segment number into an 
addresaln* descriptor (ADS) that allows the hardware to address 
the representation of a segment. 

The processors we have described look up the address of 
a segment in their addressing descriptor associative memory and 
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validate their authority to reference the segment with respect to 
the appropriate protection descriptor found in their protection 
descriptor associative memory. When one of these descriptors is 
not found in its associative memory, a hardware fault will be 
recognized. At this point software may intervene and take the 
appropriate steps to load the necessary descriptors and restart 
the faulted program. 

Clearly the security kernel must control the 
manipulation of the protection descriptor and addressing 
descriptor name spaces. This is necessary since there exists a 
one-to-one correspondence between addressing descriptors and 
protection descriptors which must be maintained to preserve the 
integrity of the system's access control mechanisms. Figure 2-k 
refines our previous model by supplanting the protected segment 
number to segment and access control list mapping by the four 
protected mappings described above. 

USER ORIENTED MACHINE ORIENTED 
NAMES NAMES 

PER-SYSTEM <PATHNAME> ++++++ <UID> +++++++ <SEG/ACL> 

+ + + 

PER-ADDRESS SPACE <SEGNO> + <ADS> t I 

+ + 

PER-DOMAIN <pj 3 > ++ ^ +++++++++++ t 

Figure 2-4: Local Descriptors 
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2.6 Local User Oriented Barnes 

We have seen that efficiency eoifslderations require our 
model to support a li»it«d~s*repe^ machine-oriented name space. 
It is only natural to ©oitatder whether there would be any 
advantages in o»r model also scrpfiopting a user-oriented name 
space of limited scope. The answer is, quite emphatically , yes. 

Like the segment number name space we have defined, a 
user-oriented name space of local scope would be easier and 
faster to search than its global counterpart. But more 
important, it would provide a private name space that could be 
manipulated arbitrarily without worrying* about interactions with 
processes outside of the scope of tHe name space. This latter 
ability is necessary in providing modular programming facilities. 

It is clear that a program should not code into Itself 
the unique identifier or even the pathname of another program, 
such as a square root program, that It wishes to call. This 
premature binding between modules would require that the first 
program be changed and recompiled if a new and better square root 
program was added to the computing utility. The caller of a 
square root program does not, in general, wish to be bound to a 
particular square root program. If the choice of which routine a 
procedure is to call can be delayed until the call is made, then 
we gain much flexibility. 
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We call a name that one programs uses to refer to 
another program a reference name. [01 ] If Its meaning is only 
defined in relation to a local name space. Such a local 
user-oriented namespace is oalled a reference name space. One 
way to implement a space of reference names is to maintain a list 
of reference name to segment associations [01). Another 
mechanism for realizing a reference name space, found in many 
contemporary computer systems [J1, 11], iavtolves searching an 
ordered list of specified directories, oalled search rules, to 
resolve inter-program references. Reference names provide a very 
useful mechanism for combining separately conceived subsystems 
and testing new subsystems all of whose odttpoh*hts have yet to be 
written by allowing reference name to segment binding to be 
defered until the components of a subsystem are combined for 
execution. 

In our model, each domain will have a private reference 
name space. This minimizes the problem of naming conflicts and 
allows each protection domain to operate without regard to the 
reference names used in other domains. A further advantage of 
per-domain reference names is that they need not be explicitly 
protected or controlled by the security kernel. Since reference 
names are private to a protection domain, each domain may freely 
manipulate its own reference name space. All that is required is 
that the reference names of each protection domain be stored in a 
segment accessible to only that protection domain. If reference 
names spanned protection domains, it would be necessary for a 
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security kernel mee&a*iMft t© coatrol the manipulation of 
reference names to prevent one <t©ttalifc from exerting uncontrolled 
influence over another deaain through the manipulation of 
reference names. Figure 2-5 shows the relationship of the 
unprotected reference name space to the other name spaces 
described so far. 



USER ORIENTED MACHINE ORIENTED 
NAMES NA#fS 

PER-SYSTEM <PATH«AME> ++++++ <UID> +++-M.++ <SEG/ACL> 

+ + + 

PER-ADDRESS SPACE <SEGNO> + <ADS> + I 

PER-DOMAIS REFERENCE NAME> . ! ++ <PDS> ++++++++I 



Figure 2-5: Local User-Oriented Names 



2.7 Summary 

In this chapter we have investigated the basic roles 
played by name spaces in a typical computing utility. Of the 
eight name spaces we have described, only the per-domain 
reference name space may be excluded from the security kernel 
without jeopardizing the ability of the computing utility to 
control user interactions. The critical difference between the 
reference name space, which can be uncontrolled, and the other 
seven name spaces we have considered, which must be controlled, 
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is that the reference name space is not common to multiple 
protection environments. Since it cannot be used by one 
protection domain to exert influence over another protection 
domain, it need not be implemented in the security kernel. 
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Before approaching the specific problem of defining a 
security kernel for the Multics system that does not support 
unnecessary name space management mechanisms, we will present a 
detailed model of the Multics system and show its correspondence 
with our general computing utility model. Our Multics model 
contains four components: a storage system model, an information 
protection model, an address space model, and a reference name 
model. These models will contain sufficient detail to allow the 
reader who is unfamiliar with the implementation of Multics to 
comprehend the important details of the design we will present. 

3.1 Storage S?atei fto,tiel 

The Multics storage system (1) manages two distinctly 
different types of objects called segments and directories. 
These objects are organized into a single system-wide tree 
structure that is known as the storage system hierarchy. This 
hierarchy implements the system's human-oriented global name 
space. The internal nodes of this hierarchy are directory 
objects. Each directory object is itself composed of a named 



(1) A more complete description of the Multics storage system 
than will be presented in this section may be found in Organick 
[01] and Bensoussan [B1J. 
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collection of entries, one for each immediately inferior segment 
or directory in the hierarchy and one for* each link in the 
directory. Links are psuedo-objects in the hierarchy that allow 
an object to appear to reside at several distinct nodes in the 
hierarchy. To accomplish this, the directory entry of a link 
contains the pathname of another object or link in the hierarchy 
that is to be considered as the target Object of the link. The 
directory entry of a segment or directory otrject contains many 
important attributes of the object, Among the^e attributes are: 
a system-wide unique identifier, a collection of human-readable 
names for the object that are unique Wthin the directory, an 
access control list, and a file map for the object that allows 
the system to access the object. 

Each directory in the Multics hierarchy is stored in a 
separate segment* Many advantages aeerue frOm supporting a 
hierarchical name space whose directories are implemented in 
separate segments. These advantages are closely interrelated. 
First, since each directory contains only a small fraction of the 
total name bindings represented by the hierarchy, it may be 
searched much more quickly than a corresponding single segment 
implementation Of the whole hierarchy. Finding a name in a 
hierarchically organized name space requires searching only those 
directories defined by the prefixes of the name. In general, 
this will represent a substantial '^savings in search time. 
Second, the component names in a directory may be viewed as 
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uniform, unatPuotured names,. Finally,, the names in a directory 
can be relatively/ small and yet still b» unique* 

As we have mentioned, a pcaotieal computing utility 
cannot assume that all users will be benevolent with respect to 
their maaipulatAoJ* of a global, shared name space. We must 
assume that some user* through raaJ4.ce or aocident, will attempt 
to delete or modify name bindings that other users are depending 
upon. If this global name space is to be useful^,, then users must 
be able to control or at least know who may change the name 
bindings that are of interest to them. Controlling who may read 
the name bindings in a particular direofeory of a shared name 
space is also desirable since the names in ■■■..;■* directory might 
themselves constitute sensitive information. 

Since segments are the ba«ic> unit of access control in 
Multics, it is only natural to control the manipulation of the 
names in a directory by the Mu^fcies segment access control 
mechanisms. This approach is quite attractive since it allows 
the name bindings in a name spa,ee to be protected without 
introducing any new, special purpose access control mechanisms. 
The access control list of a directory specifies which principals 
may read and write its representation. In this way, the normal 
access control and authorization mechanisms of Multics 
automatically provide a certain degree of control over the 
manipulation of names in its hierarchical name space. Multics 
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actually provides finer access control on directories than is 
afforded by its hardware enforced access control mechanism by 
encapsulating directories and a set of system-supplied procedures 
which manipulate directories in a protected subsystem [S1]. The 
procedures in this protected subsystem, which must be a part of 
the security kernel, exercise control over the use and 
manipulation of the name bindings in a directory. 

If we assume that the root directory of the hierarchy 
is its own parent, then every object in the Multics storage 
system has a unique parent directory. Furthermore, since the 
hierarchy has the structure of a tree and names of directory 
entries are unique within that directory, we can specify an 
arbitrary object in the hierarchy by an ordered list of entry 
names. Such a specification is called a pathname. The first 
component of a pathname names an entry within the root directory, 
and each additional name specifies an entry within the directory 
specified by the list of names that proceeded it. By convention 
we take the name of the root to be the null name, and we write 
the pathname a, b, . .. q as >a>b>.,.>q. 

A leaf node of the Multics hierarchy can be either an 
empty directory, a link, or a segment* Segment objects, which 
are implemented directly by the Multics hardware, are primitive 
objects in which programs and data are stored. 
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In Our general computing utility Model a directory 
entry consists of one name to unique identifier tapping stored in 
a directory ©f the user-oriented ftierarohioal name space. The 
issue of where to store the access control list and other 
attributes of a segment or directory, which was not addressed by 
our general model* was resolved in Multics by merging this 
information with the entries of its hierarchical name space. 
This scheme has three important consequences. First, because a 
directory entry contains the attributes Of the segment it names, 
no two directory entries in the hierarchy are allowed to describe 
the same segment* (1) This requires that an entry contain all 
synonyms of the object it describes. In Oui* general computing 
utility model this was not necessary since there was no penality 
associated with allowing multiple entries (single name to unique 
identifier mappings) to denote the same object. 

Second, the unique identifier to segment name space of 
our general computing utility model exists in Multics only as a 
collection ©f individual mappings Scattered throughout all 
directory segments in the hierarchy* This renders the task of 
locating a segment given its unique identifier prohibitively 
expensive* However, Multics does use unique identifiers to 
facilitate the determination of whether two objects denoted by 
different pathnames are in fact the same object. 



(1) If this rule were not obeyed, then the system would be faced 
with the error-prone task of maintaining identical, but separate, 
copies of the attributes of a segment. 
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Third, because the acoesa control list of an object is 
stored in the object's superior directory, it is not possible to 
have the access control list on that object arbitrate access to 
the object independent of the access control lists on the 
object's superior directories. TO see that! this is true all we 
need do is consider the foil cwing scenario of a process 
attempting to reference a segments Aaauwe that the access 
control list of the segment spec if ies? that the process is 
authorized to reference the segment, but that the segment's 
directory entry resides in a directory to wWich the process tias 
no access. The system is faced with a falri^oxv-If it allows the 
process to reference the segment, then it^muat allow the process 
to use information in the segment*s directory entry. But the 
process is not authorized to use information in the directory 
containing the entry. Thus, if the Bystem J parmits the process to 
reference the segment, then it must ^folate the authorization 
specified in the access control list of ? the containing directory. 
Conversely, if the system does riot periit the process to 
reference the segment;, then it most violate the authorization 
specified in the access control list ^ of 5 the segment. This 
dilemma will be discussed in detail in the ffefct chapter. 
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3.2 Information Protection- Modal 

The active agent of computation in Muitics is a 
process. A process may execute 4nstructi©f*fb ' in any of eight 
protection domains, numbered from to 7, fteeoe domains have the 
property that a process? access rights* to ote^e^tsin the storage 
system while executing in domain n. are a amtaaet of its access 
rights while executing in domain i**1 . itomaims that are so 
constrained have been named ring®- {S2J* To Identify the user on 
whose behalf a process is executing instruct ions, the system 
associates with each process an unforgeable principal name. This 
access control, name is used to establish a process' rights to 
access d irec tories and segments in the storage, system hierarchy . 

Associated with each segment and directory in the 
storage system hierarchy is an access control list which, in 
conjunction with the access control name and ring of execution of 
a process, completely determines the access rights of that 
process to the object. The access control list in the directory 
entry of an object encodes the s accejas mode or rights each 
principal is to have to the associated ohject in a given 
protection ring. (1) 



(1) In the current Muitics implementation both a segment's access 
control list and its ring brackets must be considered to 
determine the access rights of a principal to the segment in a 
given ring. Since this level of detail is unimportant for our 
purposes, we will imagine that a segment's access control list 
alone is sufficient to determine access. 
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When a process attempts to reference a segment or 
directory, the system evaluates the process* access modes to the 
target object. Conceptually, this involves searching the access 
control list of the object. This information is used to validate 
the process' right to perform a given operation upon the segment 
or directory. In the case of evaluating access to segments, 
Multics relies upon the hardware associative memories described 
in our general model to make access validation efficient. 

For segments the valid access mode's are read, write, 
and execute. These access modes are enforced directly by the 
Multics hardware. The valid access modes for directories are 
status - the right to read the attributes of the entries in the 
directory; modify - the right to change the attributes of the 
entries in the directory; and append ~ the right to add new 
entries to the directory. ©ireetory access modes are 
interpretively enforced by the Multios security kernel. 

Links, which are not full fledged objects in the 
Multics hierarchy, are not given an access control list. 
Instead, access to read the contents of a link is granted to any 
process that has status permission to the link's containing 
directory. 
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The process of a normal uaerexeoutea in protection 
ri.ng four., This ailowa the process to access only those segments 
and directories; W which it has nan* nul 1 aooaas in ring four or 
some higher j^jmbered ring, in order to access a storage system 
object accessible ito th»e pjrooesa ooiy,tn rtaigs numbered lower 
than four,, a. user process must. imte& an appropriate lower ring. 
This may be done only by calling a ptNxreduri© w&ich is designated, 
by its access oontrol list, as a gate into that ring. When such 
a gate procedure is called, the process enters the inner ring. 
By virtue of its naming entered, tm d&mr ring,, the access rights 
of the process may increase, When the proceaa returns from the 
gate procedure, it reenters Its prjevi4>us ^ing; of execution and 
relinquishes the access righJta it gained oh efttry to the lower 
ring. To put teeth int*» this pro tec tJUtt'< mechanism, the storage 
system manager will not alio* a ppooess to create a gate into a 
lojjfer ring, than the ring th# process is c«rr«fttly executing in. 
This insures that only procedures authorized to run in an inner 
ring may create gates into that ring. (1) 

The Mult ios system takes advantage df this ring 
protection meohaeisn} to protect its security kernel programs and 
data bases from tampering by noa*a&ftixnei procedures. This is 
accomplished by setting the access control lists of security 
kernel procedures and data bases to indicate that they may be 



<1) More complete descriptions of the Multics protection 
mechanisms may be found in Saltzer [S3], Sehroeder [S2], and 
Organick [01]. ' 
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accessed only by processes executing in protection ring zero. 
Entry points in the security kernel which are callable by 
non-kernel procedures are declared to be gates into ring zero. 

3 . 3 A<3<3r3g,g SPflgg t\QM 

The Multics system associates an address space with 
each process [B1]. The function served by this address space is 
to provide a mapping from a small set of virtual addresses, 
called segment numbers, that can be direetly- translated by the 
Multics hardware, onto the much larger set of objects in the 
Multics hierarchy. This segment nujmber address spaoe corresponds 
to the local machine-oriented name sfcace defined in our general 
computing utility model. In the Multics system every process has 
a potential address space of several thousand segment numbers. 

The binding of a segment mm be r to a 'storage system 
object, which incorporates a storage ay stem object into an 
address space, is called initiation,. Th# ,«fxf«ct of initiating a 
storage system ob^eAt is to make, jth* representation of that 
object appear directly addressable by the haf*dware of the Multics 
machine. Since Multics relies uRo^^ddressiLng and protection 
descriptors, such as those described in our computing Utility 
model, to imp 1 erne nt hardware references fc© segments, only a 
fraction of the hardware segment number to segment mappings 
implied by a process 1 address space need exist at any given 
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instance. As in our computing utility model, the Multics 
security Icerst**! haaidle* faults csa«H5^# by attempting to use 
missing 4e#cNrlp*©i*s =■ fey reloading the *la«*ftiig ad dossing or 
protection descriptor and restarting the faulted process. The 
unbinding of a storage system object from a ^^»(%^t mftrtrer, which 
removes the object from the process' address space, is called 
termination. 

Our discussion may have lead the reader to the 
conclusion that a process may have several segment numbers bound 
to the same storage system object. Actually, this is not 
permitted by the address space manager. During the initiation of 
an objeet, the address space manager locates the directory entry 
of the object from which it fetches the sf stem-wide unique 
identifier of the object. This identifier is looked up in a 
per-process table (1) that maps unique identifiers into segment 
numbers. If the uniqae identifier is found In this table, then 
the object is already in the address space of the process. This 
being the case, the initiation primitive returns an Indication to 
this effect as well as the segment number that is bound to the 
object. This scheme has several a^v*htages. First, it helps a 
process conserve its segment -numbers - a very scarce resource. 
Second, it permits a process to test the identity of two objects 
in its address space hy comparing the segment numbers assigned to 



(1) See appendix A. 
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these objects. Finally, it simplifies the management of the 
Multics virtual memory. 

3.4 Reference Name Space Mori*! 

We have asserted that local user-oriented name spaces 
in a computing utility need not be part of its security kernel. 
This claim not withstanding, the Multics supervisor implements a 
reference name space for every ring of every process. These name 
spaces provide a mechanism for mapping character string names 
into segment numbers and vice versa. In the current Multics 
implementation only segments may be assigned reference names. 
The security kernel itself does not use reference names for 
normal segments. It does however misuse its unique ability to 
assign reference names to the segments with which it implements 
directory objects. (1) Specifically, the Multics supervisor uses 
the reference name manager to associate the hierarchy pathnames 
of initiated directories with the segment number of the segment 
containing the representation of the directory. As we will see 
in the next chapter, this presents problems when directory 
objects are renamed. This problem will be discussed in great 
detail in the ensuing chapters. 

The address space manager and reference name manager 
share a common data base in the current Multics implementation. 



(1) In non-kernel domains directory objects are sealed and may 
not be accessed as segment objects. 
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This combined data base is called the Known Segment Table and is 
documented in appendix A. The reader who is unfamilar with the 
structure and contents of the KST is urged to review this 
material. Additional information on the Multics reference name 
manager may be found in Organick [01] and Bensoussan [B1]. 
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Chanter IV 

The Multics designers recognized the advantages of 
building a computing utility on top of a central security kernel. 
As a consequence, Multics is more fortunate than most existing 
computer systems as regards its seeurability. By construction 
most modules of the Multics system are not permitted to execute 
in protection ring zero. This bulk of code is thus prevented by 
the Multics protection mechanisms from tampering with those 
programs and data that are only accessible from protection ring 
zero. These protected programs constitute the Multics security 
kernel. Although the portion of the Multics supervisor that lies 
outside of the security kernel dwarfs the security kernel in 
comparison, the modules of the Multics, security kernel are still 
quite numerous as well as complex. The object modules of the 
Multics security kernel presently represent approximately one 
hundred and fifty thousand machine instructions. These 
instructions implement in excess of two hundred user callable 
functions as well as a host of implicit system services such as 
demand paging. 

We will present a redesign of the current Multics 
security kernel that will enhance its certif lability by reducing 
its size and number of external interfaces. As. a side effect, we 
will also improve the modularity and coding of the area of the 
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system we will investigate Our Aaatgn will eliminate the need 
for the Multics security kernel to support reference name 
management. This requires that we carefully redesign and 
remodularlze ring zero so that it is independent 6 f the reference 
name manager. This is necessary since a security kernel must not 
depend upon the correctness of procedures outside of the kernel. 
Before getting into the detail* of oar design, we will 
investigate the reason behind ring aero's current dependence on 
the reference name manager. 

H.1 Security K e rnel aeoeadence on Refef-ew* «frto tiaflMeWt 

While there does not appear to ©e any intrinsic need 
for the Multics security kernel to support reference name 
management, its removal from rih# fcero is eoSmplleated by the fact 
that the Multics adores* space manager usee the fa eilitles 1 of the 
reference naoe wanager to maintal* an ae*«ei«t ion between the 
pathnames of directories it -1ms initiated in a process and the 
segment numbers of these directeriee. The «d#re«s space manager 
uses these association* to avoid having- to repeatedly resolve 
identical directory pathnames into segment numbers. Since the 
security kernel must not depend upon a mechanism outside the 
security kernel, it is necessary to deeoiapte the address space 
manager from the reference name ifieheger before the latter can be 
removed from ring zero. 
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The dependence of the address space manager upon the 
reference name manager manifests itself in the recursive 
procedure fin€_ which the addreea ^Sptce ma'nage¥ uses to resolve 
directory pathnames into directory - ; -:eegme-frt d numbers.^ This 
resolution is necessary since the hardware base of the system 
only implements references to storage system objects by segment 
number. When find_ is invoked to ^ite^iiie the segment number 
for a directory, it calls the reference name manager to map the 
pathname it is given, interpreted as a reference name, into a 
segment number. If the pathname is "a Reference hame known in 
ring aero of the process; then^ fiiid_ 3 Mfiurhs^the associated 
segment number as the segment number '8f j tfft# directory. ( 1 ) it 
the pathname is not a known reference name, 'ffien firid_ splits the 
pathname into a pathname of tifre parent director^ Of the target 
directory and the directory entry name of the target directory. 
It then calls itself ..recursively wta~obt*i» a eegmen-t number for 
the parent dir«ot«isrv Using this segment tw^ber'to reference 'the. 
parent directory^ flnd_ % att empts' f -to • %&tiate^ the target 
directory. If it succeeds, it calls the reference name manager 
to bind the pathname] of the target^d^eTCtc^y, as* a re^e¥enoe 
name, bo the segment tfumbW" assigned W- the l^^et; dWeistory . 



( 1 ) As we will see latere this can >feill?e prdljl^iiis sincr thi^ 
segment number may no' longer be beulh 5 *' to '-i&e tffl^^bt^" spebif ied 
by following the pathname f indl *a« gi^en^ s%*f o| r ' %tep ^hroiih 
the directory hierarchy. ..- ' * v " f ^ y ' 
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T&Ib thesis suggests a radical change in the ring zero 
address spacf . manager. The .easen£4#J. reaitlt ©f tMs change is 
that find,., as de»^ihed above, need ^o r longer be called by ring 
zero. This allows both Xiad_ ao4 reff ren|ie na»^ «aaa«ement to be 
removed £romvrin$ f £ero. r ,. 1P . . .^... .,,_, r> 

4 • 2 Source of the Dependence 

One of the basic g©«4a ; of the Unities protection 
mechanism is that a profeas s shou|4, fc -ba, unable to detect the 
existence of a v sfc«rage system abject |© w^ch it has no access. 
(t) A second basic gpal t qf tl^HuJtfeififtegretiectian ««e»anism is 
that the access .fcentrol ;!! li,at a#' ; an(to*^e%.sk©uld be the sole 
specifier of access to the object. (&> l 



(1) We will consider*, that if a ^.^oc^^^MmtmoQ^m ^^"-J^he- parent 
of ah object then it has sufficient access to determine the 
existence ,p£ the nM«At. Tha reaaon f or iMtim w^Mi< %«- discifssetf 
latter. — 

(2) This goal was hot originally embodied in the Multics design. 
Originally a procesaV access, ,to ; an ob^ecst. waa,,,*. function of t&ree 
different access control lists. The first list wad part of the 
directory entry oi\,fche objact - an^* vOpwiMMMnta&'ttfc k the: access 
control list we now have. The second list was part of the 
object's parent and was common to all entries in the directory. 
The last list was a one per system master access control list. 
The result was a very complex access evaluation mechanism that 
allowed an unwary user to increase a principal's access rights to 
an object by removing that principal from one access control list 
when his intention was actually to deny the principal access to 
the object. The comptwrttf 'or This mechanism' so confused users 
that many of them did no,t attempt t© ■vmm'&ktowf stem provided 
protection mechanism. With the current Mai ti.es design a usar 
needs only review one access control lis* t<^ determine who has 
access to a given segment. * > 
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These goais have made the determination of .whether a 
process should be permitted to initiate, an arbitrary directory 
quite difficult. This difficulty stems from the fact that the 
access control list of an object and l£a physical storage map 
reside in its parent. Since we wish the access .control list of 
an object to exercise complete control ovta*» access to that 
object, we must permit a process to ini^ia,te ^all superiors of 
accessible segments independent of access, to these superiors. 
But this violates our second goal. 

Multics attempts tp resold the oo,$fliot outlined above 
by not permitting a process running; outsi^e^ of r ring zero to 
initiate a directory. Since a process, caina<>t : read the access 
control list of a segment until its parent is known, the system 
still must permit processes, while executing in ring zero, to 
initiate directories that they may not have the right to know 
exist. By causing the initiation of .these superior directories 
to occur in a single, indivisible ring zero call, the system 
could, in principle, prevent security leaks. This. could be 
accomplished by terminating those intermediate directories that 
had to be initiated only to find that the process had no access 
to the terminal segment, before returning t© the caller. 
Unfortunately, Multics system 24.2 does i*ot do. so. As a result, 
any process can determine the existence of : any postulated 
directory by attempting to initiate any 4 arbitrarily; named 
descendent (which need not exist) of that directory and observing 
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how many segment numbers were allocated by ring zero. This is 
possible because all rings share a common address space. 

It would be relatively easy to correct the 
implementation flaw in ttie Multlcs address space manager pointed 
out above. However, the system vould still 1iave to be very 
careful to avoid compromising infortnatibtt. for example, * suppose 
a process filled up its address Spac% intentionally and then 
called ring zero to initiate >secret>x. " ; 'l¥ ring zero was not 
very careful, it might cause the process to die due to its 
inability to find an unused segment humter to bind to >secret, if 
and only if xseeret existed. This would* allow" the existence of 
>secret to be inferred by whether or hot the process died. 

The inability of a process to initiate directories in 
outer rings directly has led to many heedlessly complex 
mechanisms for manipulating directories. In addition, it has 
forced us always to t-ttur to directories by pathname in the 
security kernel interface. Hot only is this inefficient, but it 
has led to ring zero's dependence upon fitfd_. If we could 
initiate directories directly outside ring SeVo, then the ring 
zero interface could take a segment number' irttftead of taking a 
pathname as a directory specifier. ■ Since ring zero would no 
longer need to call find_, it could movent o^rirtg zero, along 
with reference name management, without compromising the security 
of ring zero. 
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1.3 Removal of the Dependence 
4.3.1 QverYJgW 0f the Pegifin 

We propose allowing directories to be initiated by 
processes executing in all rings. As was rioted earlier, the 
basic problem to- be solved is that of deciding whether a 
process should be allowed to initiate a directory to which it has 
no explicit access. (1) There are essentially four Schemes for 
making this decision. The first scheme involves recognizing that 
if the access control list of a directory/ is to completely 
express access to that directory, then we last make explicit the 
now "hidden" permission to initiaitr a directory if some 
descendent of the directory is accessible to the process. The 
obvious way to accomplish this .is to invent a new directory 
access mode oalled "initiate". This mode would allow the named 
principal to initiate a directory and to use 'the information it 
contains that is releverit to accessing deseendents of* that 
directory. This makes the decision of whether or riot a process 
should be allowed to initiate a directory quite simple. If the 
process has non-null access to the diredtdry, then it may 
initiate it. Otherwise, it may not. 



(1) The reader should note that we are ignoring k for the purposes 
of this thesis, the possibility of solving tfil problem outlined 
above by removing the attributes of a segment from the directory 
hierarchy. Removing the attributes of i segment from its parent 
directory, which may be the best long term solution, seems very 
attractive but requires a fairly extensive overhaul of the 
system. This thesis will investigate less drastic solutions to 
the directory initiation problem which do not disturb the 
structure of the Multics hierarchy. 
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This scheme does not meet the. goal thatU'-tfe-e -access 
control list of an object completely ^xjresa^fhieh.proeeases may 
access that object. While explicit initiate permission is 
probably a workable, solution, and it* s t *im»U«4l^ is appealing , 
adoption of jue| a solution woul4 produce a quite notieable 
change in the system's functionality, v We, choose wt a explore 
alternative , solutions thjat ma^i|t%^ ^ dt^ .curreatr system's 
functionality, !■,■>■ -m" ■■'■o.s- , . : 

A way, to maintain the current jfeg^fcfeMH&fcfey of Multics 
using explicit initiate permission : ia to ,,< couple the access 
control list on an i ,ejb ( ject witb« th* ; .me cjps ;jOji*trs&v^is%» .-o» all 
superior directories^ ,a©, f that when .+nmm*m i*; given afcoeaa to 
an object it |s, aiso gj.ven initiatf* access to all superior 
directories of that object, . . Whea. , a; s prp®e»»ij8afe8e44iently is 
denied access , £o, an f object , the see^r^,. k# raej. i mmt. .- remove .. any 
initiate permission that the proceaa, ,^Mh to the ; superior 
directories of t^heob^ct, , and that, r*s|$teds rseleiy from its 
having, access. to the, object. ^e£eraini»gv s wh.ieb initiate 
pe.rmissions ;r should.be, remgve^ <is ^ver^ -d^ffi^ult* potentially 
requiring that the entire directory hierarchy, fee examined. 

A second way to dedlde whether "a process may initiate a 
directory is to searoh the hierarchy . subtree rooted at that 
directory. If the pr.'ocess has noa-n,uil, adeems to any member of 
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this subtree then the process should be allowed > to initiate the 
directory in question. Naturally, this ^scheme is far too 
inefficient to consider seriously. 

A third method of deciding whether a process may 
initiate a directory is to require non-null access to the 
directory. This scheme has the disadvantage, shared by the first 
scheme discussed, of preventing the access control list of a 
directory or segment from being the sole arbiter of access to 
that directory or segment. In order to initiate a segment, a 
process would need non-null access to the superiors of that 
segment. 

We propose a fourth solution to the problem of 
initiating directories. Instead of worrying about whether or not 
a process has the right to initiate a directory, let us allow all 
processes to initiate any directory - whether or not it exists. 
The key to this scheme is preventing the process from detecting 
any difference between an Initiated directory that does not exist 
and an initiated directory that exists but that the process has 
not proven its right to know exists. How this is to be done 
will be discussed later. 

The ring zero address space manager interface resulting 
from this approach seems quite natural. Ring zero no longer 
concerns itself with pathnames. Instead, it accepts directory 
segment numbers for directory specifiers. To allow this scheme 
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to bootstrap itself* we will define the segtoent number of the 
parent of the root to be zero. Initiation of segments and 
directories will be controlled by the prdsedure initiate., that 
will accept a parameter specifing whether a segment or directory 
is to be initiated. 

The rationale behind distinguishing directory and 
segment initiation is that a process usually has a preconceived 
idea about the type of the object it wishes to initiate. When 
reality does not support this preconceived idea, the process is 
usually in error. Forcing the process to make explicit the type 
of object it is expecting allows ring zero to immediately catch 
many such errors, preventing a careless process from bumbling 
along thinking all is well only to die when i,t attempts to access 
a directory as a segment or vice versa. Naturally, it would be a 
security violation for the kernel to report a type violation to a 
process that has no right to know whether the directory or 
segment named actually exists. If a segment or directory should 
be undetectable to a process, then the security kernel must treat 
it in a manner consistent with the type specified in the initiate 
call regardless of its actual type. 

To complete our new ring zero address space manager 
interface we must define a new termination primitive. This 
primitive will accept two arguments, The first argument 
specifies the segment number to be terminated. The final 
argument is a status code. It should be noticed that this 
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primitive may be called with either a segment or directory 
segment number. In the case of terminating a directory, one 
constraint is enforced. Since the system requires that a known 
segment's parent also be known, terminate, will not terminate a 
directory with known inferiors. 

4.3.2 Details of the Design 

So far everything seems rosy. This scheme seems to 
remove many functions from ring zero and to simplify the ring 
zero interface in the bargain. Where is the hitch? Do we get all 
this for free? The answer is, of course, no. We have glossed 
over one important point. In order to decouple directory and 
segment initiation we must be able to successfully cloak the 
physical initiation of directories from a process' detection 
until it has established its right to know of the existence of 
the directory. As was pointed out earlier, this need for 
deception is intrinsic to the hierarchy structure and 
functionality of the Multics system. While this design makes the 
system's need to deceive the user more obvious, it is not 
responsible for the required deceit. 

We will call a directory detectable if a process has 
established its right to know that the directory exists. 
Detectability may be established either by having non-null access 
to the directory, by having non-null access to its parent, or by 
establishing the detectability of an inferior of the directory. 
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The reason that non-null access on -the parent of an object 
establishes its deteciability is that el-the** 1 status; modify or 
append permission to a directory is i*#fief*%t i^ allow a process 
to detect if a postulated entry in that directory actually 
exists. It should be noted that the dtteetioiilty^Qf a dlrectbry 
is dependent on the process' history and the ring of execution. 

A directory is detectable by a process in rings zero 
through the highest ring in whieh it has l detecS#bly initiated 
some member of the tree rooted at that ^ireirt^iry. this highest 
detectable ring number of a directory It^^tiM n fts iCSTE. try 
We will not attempt to reset this f i#M-8%ouM a offer detectable 
directory subsequently become und*et*oti*ble. - ; - c Hot? ^tteiipting to 
reset the highest d*4*ctabla ringfiefl* in !d t**e - r <iSftAt of an object 
when it hecomes undecteotab&e to the ■ : > : tftH$m&a makes -*#tse since the 
system has already admitted • the^xi slider of th« idfir^tory to the 
process. The process ^couPd have ^stored 1 ' this information 
elsewhere, so it would he of little use to d^iiy^iihe ^existehce of* 
the directory. The record kept in the fS^r «# 1^ Hxistehce of 
the directory *wi!4 naturally vanish wtretF ^ftie ^directory is 
terminated or when the process is de^tr^yad-; ' ~~ li 

We must prevent a process from detecting any difference 
between an initiated directory that does not exist and an 
initiated existing, but undetectable, directory. If a process 



(1) See appendices A and B. 
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could detect a difference in these two oases then it could 
establish the existence of any postulated path in the hierarchy. 
This would constitute a clear violation df security. To 
accomplish this means abandoning the current one-to-one mapping 
that exists between occupied segment numbers and initiated 
segments and directories. Although we will #tlll only allow one 
segment number to be bound to a segment, we must allow multiple 
Segment numbers for the same directory. 

The reason for this dichotomy between segments and 
directories is simple. Since the access control list of a 
segment completely controls the rigfet to initiate that segment 
there is no need to allow a process to initiate a segment to 
which it has no access. This allows us to hide the physical 
existence of a segment from a process that has no right to know 
of its existence by returning the ambiguous status code "ncinfo" 
in response to an initiate request. This simple mechanism fails 
for directories since we must always allow a process to initiate 
an existing directory in ease it has a#©ess to some inferior of 
that directory. This forces us to return more than one segment 
number for a directory in some cases in order to prevent the 
process from detecting the existence or physically initiated but 
logically undetectable; directories, . 

There are two characteristics of Multics that 
necessitate our abandonment of the current one-to-one mapping 
between directory segment numbers and directories. First, 
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directories can have multiple en*ry names. If*lhltiate_ returned 
the same segment number for two different entry names withiri a 
given directory* then the process wou&d know that these nameV 
both named the, 5 aame directory. This coincidence of names would 
establish the existence of t^ -ddreefeoqy (if ttm directory did 
not, , eatiat, . 4 then hsow couldk it >•&*& -Hmo ■-i&amW* To prevent the 
coJj^Aidence of multiple ©ames -oat a d4r38fet^yi^i*c% revealing "the" 
existence of the directory^ «m»- must - : iwtaaw^'-nW Segment number 
if a process reinitiates a directory that is still undetectable 
W W a new,, name. In fact, ^we w^ii even re4t*Hn a hew segment 
number if it tries to initiate an undetectable directory with the 
same, name twice, If we returned the same segment number^ then in' 
order for directories that do . no* P phymicaiay **ist to appear the 
same to, the user ring, ring zero wdold htve^t© remember the name 
of every phoney directory*. ?his is a needles* u ediplication of 

The second characteristic ®f tfctl'tic* -that forces our 
abandonment of tl|e : .one-to-o#e mapping between ^l^Gtory segment 
numbers and directories ia ^hat .the segment 4M**ber» o* a process 
are a finite resource shared among all protectee* 1 rings of that 
process* As we have, eomimantesd eaa*lierv : %h* ^fteaW size of the 
Multics shared segment number addj^ss- «|me¥ altow* > on© ring to 
detect the number of segment numbers being used by all other 
rings. This makes it necessary to assign a new segment number 
whenever an attempt is made to initiate an undetectable 
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directory. This segment number must not be shared with another 
ring so long as the directory remains undetectable. The need for 
assigning private, per-ring segment numbers to undetectable 
directories may be seen in the argument that follows. 

Assume the system returned the same segment number when 
asked to initiate a directory in two different rings. Assume 
also that the directory is undetectable in the upper of the two 
rings. What is the system to do wherr asked t© unbind the segment 
number from the directory by the upper ring? It cannot unbind 
the segment number and return it to the list of free segment 
numbers since a lower ring is using the segment number. 
Unfortunately the ring that requested the system to terminate the 
segment number can detect whether or not the system actually 
returned the segment number to the free list so the system cannot 
just pretend to honor the termination request. If tfte segment 
number is not freed then the ring can deduce that some other ring 
has the directory initiated. By an argument similar to the one 
given in the previous paragraph the ring caw conclude, from the 
coincidence of two rings having the directory initiated, that the 
directory actually exists. Since segment numbers are a scarce 
resource, the system cannot take the easy out of not allowing 
undetectable directories to be terminated. As a result, 
initiate, must assign a new segment number whenever it initiates 
an undetectable directory. 
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The reader should nofcetaa* we have Ignored, up to now, 
the problem of preventing a process ff»ea distinguishing between a 
non-existent directory *ad so existett but andeteotable directory 
through obseryjation audi ?aita$ji»$«sof <ise*af>« ^#**der effects such as 
the time required to initiate or terainate a directory. It is 
hard to predict An advance of ins**Maf*®ii ?in %he standard system 
what sort of second or^** effects - vtiLgHV ■ fce c*bWrved. the plan is 
to investigate =fchia problem fallowing *<Stual installation. 
Timing differjeai&ea can &*; ««slliy bidden *yiftsel*tlng extra code 
in the shorter path, — 0tto*r difTefreneea also probably are 
disguisable. , 

This soheme will merrily allow a process to initiate 
vast tree* ,of directories that denot fii^it. Ifheate directories 
will be indistiafwisaable fpoa real &#4W&oiitif4i directories. 
The potential awltipiieity -mt ■:*«4§MMt "-'ftb&A'ria r* "for directories 
implies that if we .ccjmpaee two ^dir^t^i^%elPTO* lumbers and find 
them to be not equaJ., tfren we oannot oonclude that the objects to 
which they are bou-nd are jio|j one slid iMiefcieaate. Since processes 
running outside rijng zero cannot ourreWiy obtain segment numbers 
for directories, no user code can fcfe : affect etf by this new 
restriction. To allow froceaae^i to*«quiefcly determine if two 
segment numbers are b©*ind i© the same oejeet, the system should 
support a function Cor mapping; a segment number Into the unique 
identifier of the object to which it is bdund; Naturally, this 
function must return an error if the object is not detectable to 
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the process. The system must aiso = ii«sure that if a process 
attempts to reference through any dti%ctory' pointer in an outer 
ring, it will get the same ac%»ss tibia tloh fi whether or not the 
segment number it referenced corresponded to 5 *ir > real or phoney 
directory* , 

Figure 4-1 summarizes the Mictions ; performed by 
initiate^, when mapping a directory infco a process' address spaoe. 
The reader should note that a target -MJedi 5 within a phoney 
directory is considered a priori imde£e^a^le~ ? and a 1 non-existent 
target object is considered dete^ab^€ by: a process if the 
process has non-null aooes* to the cVBrtMinitog directory. The 
abbreviation "hdr* used in figure 4-1 ^tahdir^for the contents of 
a KSTE's highest detectable ring field. We have omitted the case 
where the target is a link as-< this : cwse vilflr hcf discussed later. 1 



.target is detectable in ring of caller " 

• ■ ■ ■ ■ ■ ■. . 

. .target exists in hierarchy 

. . .target already has a segment number ^ 

return values I internal state 
{status code j segment humfcerf u A ° ndr 



• • « 



|Q - -j ?no_info" ( new | 

! 1 -j "noentry" 
II 1 0! 

11111 "known" 



\ 

none i ........ j 

new I " ringof caller \ 

old imax(hdr,ring of caller) I 

—————*—•»— ——-^—— —..•«• «ii—.*&— .—;»..«.£«...«._.,. __ — _ 



Figure 4-1: Action of Initiate for Directories 
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Two possible op jeetions we-, can* sees to, this , scheme are 
that it can potentially *»pte s«^Mitt^«uaNfeii^r«*h* it recipes 
inspecting the parent's aeoefs,c©ft« , ol, 6 list i - A close, /examination 
of figureJJ-1 indicates that, thei^iupeh^lf^tw©^ wayso to assign 
multiple segment numbers to a directory. The first way is to 
reinitiate an undetectable directory* The aeoond is to initiate 
a phoney directory* Neither of, the** R g per at ions should occur in 
normal operation. They could , however* ri«*ise!;io. an attempt to 
use a misspelled pathname. To eostrQ J -this cpr oh lem, the outer 
ring variant of find^ could termiaafce, th^s«e- dljr«ct<xries that 
might be phoney if the terminal segment 4W>»ld not be initiated. 
This would prevent, a habitual, m4^spell*r tm* cluttering his 
address space, It seems, Jthat wlth n fchls #dd4*&o« a ? process would 
be obliged tp go out ; of its way, in #tfr*th ifrftAfeifefeer. its address 
space . jf that is ? what, it, ^iMEJts f;4nj». A&t*te *£ * process wastes 
all its segment numbers, it can recover by terminating no longer 
needed segment numbers. ,^ ,, 

The apparent inef f ioeacy of. t in#p##iJjsg; the access 
control list of the parent of a direeto#y,d»rii>gv: its initiation 
is not serious since it is no5»aliy!B#*s^sq«A#ed* Only when a 
process has null access to an object , and has ; not previously 
established detectability for thatv-ebject is it necessary to 
inspect the aecess. control list of the- parent. (}) 



(1) In fact, the frequency with which a process initiates a 

?l^t„?Z y +AS iS*?^ **>*? ha3 *& *o<»»*o4*Jtow enough in Multics 
that our test implementation does not check to see if a process 
has previously established detectability for a directory to avoid 
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In Multies system 24.2 the address space manager and 
the reference name manager share a dflta base. ^(1) The address 
space manager takes advantage of 'its abllfty to access the 
referenoe name manager's data- base by scafanhfrig the per ring, per 
segment number, list of reference halites kepli^y the reference 
name manager to determine which rings of ik procesV are still 
using a particular Segment 5 number; ftils information is used to 
prevent one ring from terminating a segment mtaber that is still 
in use by another ring. (2) Only if ail rings that Initiated the 
object have terminated it, can the segment number be unbound from 
the object. Thus, we have the concept of initiating an object in 
a particular ring rather than the concept of initiating an object 
globally in all rings of a process; Thia ? schem6 is desirable 
since all rings share the address space of sigment numbers. ^" 



inspecting the access c®nft*oi iiit <if '^fte- parent of the 

directory, if the process has null access to a directory,, then 

we always check ^he 5 p^o^e^ r acoSsr "to^fhe' par In t of the 
directory. 

(1 ) See appendix A. 

(2) Since the address space manager uses, ' t&e presence pf 
reference names in a given ring t of V J seg«*tft huirfber to detect 
that the ring is still using the segment number, the current 
initiation primitive must call the reference name manager to give 
a segment a reference name in the appropriate ring each time the 
segment is initiated. The current initiate interface supplies 
the address space manager with a *>*£wwt&& *trr thir purpose . A 
more complete description of the relationship between the address 
space manager and reference ham¥s -in* ? "sy¥tW ; '2N^lfiy: be round in 
Organiok [01], ir -> ^^ 
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Since reference names will I no longer be kept in the 
KST, some new mechanism must be invented to supply information 
about which rings of a process are still using a given segment 
number. This is easily accomplished j by adding an eight bit 
field, called rings, to each KSTE. If the i th bit( origined) 
in this field is on then thfe corres^ndiilg ritig has the segment 
number initiated. This allows ring zero to detect when a segment 
number may be physleally terminated; fcttei»eby p*>eVenfcing one ring 
from terminating a segment of directory t^at is being used by 
another ring* Ct) 

Our termination primitive marks $h> segment number it 
is given as free in its callers ring- ^ of execution. If the 
segment number is initiated in no other rings and its inferior 
count is zero, then the segment number is unbound from the object 
and its KSTE is placed on a list of free KSTEs. It should be 
carefully noted that the termination primitive terminates a 
single segment number; it only removes ah object from the 
process' address space if the last r segfetet number for the object 
is terminated. The reader steould notice that because Initiate,, 
always assigns a private segment number when a directory is 
undetectably initiated-,- terminate,, heed not worry about revealing 
the existence of an undetectable* directory i 



(1) Appendix B summarizes the content of the known segment table 
as we have redefined it. 
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1.4 Removal of Pathname P rocessing 

Ring zero's ability to resolve a pathname Into a 
segment number has been severely impaired by our design. This 
ability, which was embodied in the ring zero procedure find_, 
depended upon ring zero's ability to call the reference name 
manager . Specifically , f ind_ depended oh the reference name 
manager to maintain an association between pathnames of objects 
and the segment number bound to the object. fortunately, this 
association was only used to make find_ more efficient. AS a 
result, we could redefine flnd_ in such a manner that it would 
still operate correctly but would hot take advantage of such an 
association between pathnames and segment numbers. 

To make find_ independent of the reference name 
manager, all we would need to do is redefine fihd_ to inspect the 
pathname it was given to see if it specified the root, i.e. M > 1 '. 
If it did, then find_ would initiate the root, and return its 
segment number. (1) Otherwise find_ would strip off the last 
component of the pathname and call itself recursively with the 
pathname of the parent of the target dbject to get its segment 
number. Given this segment number, flnd_ would call initiate to 
initiate the entry named by the component which was previously 



( 1 ) The system treats the root directory as a special case. The 
location of its physical object map as well as the rest of the 
information that would reside in its dii%cttw*3r entry, if it had a 
parent, is embedded in the programs of the system. This 
guarantees that the root may always be initiated. 
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removed from the pathname. For example, if find, were called 
with >a>b it would call itself recursively to get a segment 
number for >a. It would then call initiate to get a segment 
number for the object named b in the directory >a. 

While the procedure we have described is correct, it 
appears to be quite inefficient. This inefficiency suggests that 
we should either give find, a new associative memory or move it 
out of ring zero so that it can once again use the reference name 
manager. Since giving find, a new associative memory would add 
code to ring zero which has no protection reason to be in the 
security kernel, this alternative is untenable. Our approach 
will therefore be to remove find, froft ring sara. 

The actual removal of find;, from ring zero is, of 
itself, trivial. In the outer rings it c*& access the reference 
name manager directly once again. It ; can also access our new 
initiation primitive through a standard gate into ring zero. The 
problem is that numerous programs in ring zero depend upon find, 
to map pathnames into segment numbers. Unfortunately, they 
cannot be allowed to call our new find, in the outer ring. To do 
so would jeopardize the security of ring zero. To get ourselves 
out of this dilemma* we will have to remove almost all uses of 
pathnames from ring zero. This in itself represents a 
substantial simplification of ring zero, To acoaHiplish this task 
we will consider the four major uses of pathnames- in ring zero. 
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4.4.1 Parameters to Ring ^r Q 

The first class of pathname^ used ., in ring zero that we 
will consider consists of those pathnames that were passed into 
ring zero as an argument to a gate procedure. This class 
represents the major use of pathnames in ring, zero. Fortunately, 
it is also the easiest class to remove from ;; ring, . awna. Since 
f ind_ now resides in the outer ring, we will, make the outer ring 
responsible for translating all pathnames ,<tb*fc are currently 
passed into ring zero into segment number*.. We will then 
redefine all ring zero gates that acoej>t p*$hn*mes as object 
specifiers to accept segment numbers as object specifiers 
instead. 

4.4.2 unka 

The second class of pathnames used in ring, zero are the 
pathnames contained in links. Many ring zero programs, when they 
discover that the object they are to *at u.pon is a link, are 
defined to act instead upon the target of the link. An example 
of a ring zero function that is defined to ; foUcw this rule is 
the segment initiation primitiye. (1) We propose that primitives 



(1) To prevent a process from causing ring zero, which is masked 
SI st i nteru £ ts ' fro * loo ?*»S indefinitely, fc^lswAag a circular 
chain of links, each prclram that follows links keeps count of 
r,,lJlT 1 °5 links "tra^rses during each iwocitl&fl, If this 
number exceeds a certain system-specified threshold, then the 
computation is aborted. 
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which are defined to follow links return a Status code indicating 
that a link has keen encountered as well as the contents of the 
link itself, upea discovering that their t if get is a link. 

This scheme requires that links fee readable in the 
outer rings which raises the question of what, if any, access 
control should he placed on reading links, the approach taken in 
Multics system 24.2 is to make links effectively readable by any 
process that has no^M-null access to the terminal target of the 
link. This scheme has a* inherent security flaw and is therefore 
unacceptable. If some process can guess the pathname of an 
existing link to wfeose target the presets has access, then it can 
prove the existence of the parent directories of that link by 
initiating the target object through the link, to eliminate this 
security flaw we could place access control lists on links, 
thereby explicitly naming those processes which inay read the 
link. The complexity of such a meettariis* seems unwarranted when 
weighed against its benefits. The only access control on the 
target object of the link that is guaranteed is specified by the 
access control list of that dbjeet. M? access control specified 
on a link may be avoided by referencing the target object 
directly and thus serves only to protect the contents of the link 
itself. 

The reasons that access to links must be controlled is 
that the existence of a link implies the existence of its 
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superior directories and suggests the existence of its target. 
We have chosen a simpler mechanism for controlling access to 
links which, although not as comprehensive as a mechanism that 
associates a private access control list with each link, meets 
both of the needs for protecting links. We consider a link to be 
part of its containing directory, readable only by processes 
having status permission on that directory, This scheme has the 
virtues of being simple, easy to implement, and plugging the 
information hole that uncontrolled access to links provides in 
system 24.2. While this scheme does make drie class of currently 
legal uses of links illegal, this restriction dees not seem too 
severe. 

To illustrate the scheme we have proposed, we will 
outline the redesign of link processing by the ring zero 
initiation primitive. When initiate^ encounters a detectable 
link, it will return the link and a status cede that informs the 
outer ring procedure that a link was encountered. (1) The outer 
ring procedure may then try the new path specified by the link. 
Since this is happening in an outer ring, we need no longer have 
a standard interpretation of links. Since link processing will 
be done in the user ring, the process may interpret links in any 
manner it chooses. Why not let links contain relative pathnames, 
offsets, or even arbitrary character strings? A link might even 



(1) As we have mentioned earlier, if an undetectable link is 
encountered while attempting to initiate a directory, the system 
must treat that link as an undetectable, phoney directory. 
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specify a file residing in another computer system. The 
important point is that while the kernel may be the keeper of 
links, it does not interpret them. Naturally, the restriction on 
link depth, which was intended to "* keep ring zero from getting 
into trouble, vanishes. 

^.4.3 Internally Generated Pathname* 

In a few cases, ring zero generates and uses pathnames 
internally. These generated pathnames constitute the third 
general class of uses of pathnames in ring zero. We will further 
partition this class into those pathnames that are generated only 
during system initialization and those pathnames that are 
generated during normal system operation. 

During the initialization of the Mult ics system, the 
need arises to initiate on the order of on# hundred or fewer 
segments. The reason the system must initiate these segments is 
of little interest to our thesis. We observe that since system 
initialization is an infrequent operation (hopefully once a day 
or less) and the number of pathnames to be, reaolved is quite 
small, we need not feel remorse at 4M*©Po«ing * very inefficient 
mechanism to resolve these pathnames. In fact, as the reader has 
undoubtedly guessed, we propose that these, pathnames be resolved 
by calls to the inefficient version of find., that we described 
earlier. 
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In the case of pathnames generated by ring zero during 
normal system operation, ue cannot be quite so cavalier. Or can 
we? In fact, we can. A careful examination of ring zero reveals 
that ten is a reasonable upper bound on the^ number of generated 
pathnames that must be resolved in ring zerd in the life of any 
given process. 

In fact, these internally generated pathnames are so 
restricted that we have no need to even call our inefficient 
find_. Since they all are of tree depth at nfost three and all 
components of these pathnames except possibly the last component 
are constant for all time, we could expand the code of find_ in 
line to the programs that use these pathnames; Per example, if a 
program needed to initiate >pdd>my, tfcen it ifoold first initiate 
the root. Then, given the segment number of the root, it would 
initiate pdd. Finally, given the segment huttber of pdd, it would 
initiate my. 

4.4.4 Error Common? 

The last and perhaps most troublesome class of 
pathnames used in ring zero are pathnames that are used to report 
error conditions. There exist numerous instances in the system 
where a procedure detects an inconsistency or error condition 
associated with some segment or directory. For instance, the 
system may detect an unrecoverable error while reading the 
contents of a segment. Another example would be the detection 
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that the doubly threaded list which chains the entries in a 
directory together is misthreaded. In error ;oonditions such as 
these, the system writes a message into the system- log explaining 
the problem. This message often coctaina a pathname that was 
generated from the virtual address©! the segment or directory in 
which the error oceured. While the exact algorithm for 
generating a pathname from a virtual address is of little 
interest to us, this algorithm did depend upon the reference name 
manager's ability to map a directory segment number into a 
pathname of the object it wee bound to. 

Since we have argued that ring sero must not call the 
outer ring name apace manager, we must propose a new algorithm 
for mapping a segment number into a pathnawt* Many schemes are 
possible. However, since the error ©en-dttiems we are talking 
about may be presumed to be quit* rare, we will suggest a very 
simple, but inefficient, algorithm. This algorithm relies on the 
fact that any virtual address may be mapped, by the known segment 
table, into the virtual address of its directory entry. A name 
for the segment can be found in the directory entry. This name 
is the last component name in a valid pathname of the object. To 
get the other components of a pathname of the object, we 
recursively apply this technique to the virtual address of the 
directory entry which is, of course, within the parent directory. 
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*»«5 Summary of the Design, 

This chapter has presented a design that allows 
directories to be initiated in all rings. As a consequence, the 
need for the Multies security kernel to maintain reference names 
has been eliminated. The key feature of this design is that the 
security kernel maintains, for each process, the illusion that 
any postulated directory exists unless the process has sufficient 
access to prove otherwise. This permits the security kernel to 
allow a process to initiate a directory to which it has no access 
without disclosing the existence of that directory. The address 
space manager interface presented in this design is summarized in 
appendix C. Appendix D contains an example of the use of this 
interface. 
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New Mon-icemgl Fu^l^n,? 

As a result of our design, the inter faee to ring zero 
has been modified quite extensively. We have eliminated three 
major functions that were supported by the old ri«g zero: 
reference name management, pathname resolution, and storage 
system link indirection. if the npn^cernel -portion of the 
Multics supervisor is to use these service^ or provide them to 
the users of the system, then we must design modules capable of 
providing these services that run outside of ring zero. We have 
already explained, to a degree which we hope Is sufficient to 
convince the reader, how the last function may be trivially 
performed by outer ring modules. In this chapter we will discuss 
the important issues Involved in resolving pathnames in the outer 
ring and designing an outer ring reference name manager. in 
addition, we will address ourselves briefly to the problem faced 
by user programs that depend upon now obsolete ring zero 
interfaces. 

5 - 1 Reference Name Managpr p»«|fm 

We have seen that the Multics reference name manager 
provides four primitive functions on name spaces. These 
functions provide a process with the ability to: bind a name to 
a segment number, unbind a name, determine the segment number 
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that a name is bound to, and obtain a list of thV «ames bound to 
a segment number. Actually, the Hultlo. referenbe na me manager 
provides a larger set of function*. Ho*ever, the additional 
functions all can all be expressed in terms of the four 
primitives we have described. 

It is not our intention to actually design a reference 
name manager. We trust that the reader will wo ep t our assurance 
that it can be done and that it is in fact straightforward. We 
must, however, comment on one consideration fcHWt the design of an 
outer ring reference name manager must recognize. When the name 
space manager resided in ring zero it was operating in an 
environment in which it was guaranteed to run to completion once 
invoked. An outer ring name space manager is not afforded this 
luxury. 

Executing in the outer ring environment , the reference 
name manager may be stopped at any instant. This of little 
consequence except when it is* stopped by: the Mul tics -quit- 
mechanism, m this case, the system suspends the process' 
current computation and then restarts the process, The process 
may then reinvoke the reference name manager and at a later time 
resume the suspended computation having potentially totally 
rearranged the reference name manager's data base. 



-77- 



Luckily the system provides a mechanism that allows a 
process to inhibit or "mmak* guit signals. By masking quits on 
entrance to the reiW*«ee name amm%. er antf tlfiraasftlhg quits upon 
exit the problem can be eliminated. Actually, it is highly 
unlikely that the entire computation performed by the reference 
name manager need be masked. We should design the reference name 
manager so that it has as small a »#f*it leal* aeetidn or sections 
as possible. In other words, we should try to isolate the code 
that might malfunction if it were irtot atesked against quits. We 
can then mask and unmask quits only when we eiiter and exit a 
critical section. 

Before leaving the topic of name space management, we 
should comment on one consequence of p iliSwinf processes to 
initiate directories directly. This ability allows a process to 
use the reference name manager to bind an arbitrary name to a 
directory. One immediately ofcviou* i*se of this new facility is 
to replace the current special purpose mechanism that identifies 
a process ' per ring working directory ahd ; search directories 
[01]. All we need to do is bind the appropriate name, i.e. 
"working_dir n or "searehjairjn" to the eorrii&t directory segment 
number. 
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5.2 Pathname Resolution 

We have commented that reference names are per ring. 
This prevents programs executing in one ring from causing 
programs executing in another ring to malfunction by tampering 
with shared reference names. As a result, ring four could bind 
the name "sqrt" to one procedure and ring one could bind the same 
name to an entirely different procedure. While this multiplicity 
of name spaces per process is desirable for protection and 
modular programming reasons, it partially defeats find^'s purpose 
in using the reference name manager to bind pathnames to segment 
numbers. Since each ring has a different name space, associating 
the pathname >a>b with segment number 401 in one ring will not 
help another ring resolve >a>b. The result is that many 
redundant pathname resolutions will ocour and many name spaces 
will contain identical entries, 

We suggest that find_ not use the reference name 
manager to associate pathnames with segment numbers. In fact, it 
was never correct for it to have done so. A name space just 
associates an arbitrary name with a segment number. However, 
pathnames are not just arbitrary names. Consider, for instance, 
what happens when we remove the name b from the directory >a>b 
and then add the name b to the directory >a>c. The result of 
this change in the environment is external to the reference name 
manager and yet it has invalidated a mapping the reference name 
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manager was keeping. The pathname >a>b no longer refers to the 
object that is bound to segment number 401, but the reference 
name manager has no way of knowing tfetis. 

There are potential advantages to binding pathnames to 
directories once per process, as is done in Multics system 24.2. 
Consider the problem of installing a new version of a 
multi-component subsystem, such as the Multics PL/I compiler, 
while Multics is running. In Multics system 24.2 we could store 
the components of the compiler in a single directory. To install 
a new version of the compiler all we would need to do is build 
the new version in a brother directory of the current compiler. 
When the new compiler is ready for installation all that would be 
necessary is to exchange the names on the new and old compiler 
directories. Processes that had already started to use the 
compiler would remember the segment number of the old directory 
as the compiler directory and would continue to use the old 
compiler and satisfy new dynamic linkage faults to components of 
the compiler from the old directory. In this way a process 
always gets a consistent copy of the compiler. A process that 
had not yet used the compiler would initiate the directory 
containing the new Compiler when it attempted to invoke the 
compiler. It would then remember this new directory as the 
compiler directory and satisfy all linkage faults for pieces of 
the compiler from this directory. 
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If a process does not "freeze* a directory sub-tree, as 
is done in system 24.2, when it initiates tftat directory* then It 
becomes very difficult to do on line installations of 
multi-component subsystems. A process could easily get half of 
an old multi-component subsystem and, half .of. a T new version of 
that subsystem when an online installation of the subsystem is 
done. On the other hand* a process ^f ten %ai*ts *o use the actual 
hierarchy, not a "frozen* image of :ttee* hierarchy. Our design 
allows a process to choose between tfc#s« t«o alternatives by 
supplyiing an appropriate version o# f indy in **4se outer ring. 

We suggest that the : . system .rauppliaed find_ opt for 
solving the "directory renaming problem* rather t haft? the "online 
installation problem". The easiest* and' mewfc attractive approach 
to solving the directory renaming problem is to not allow find_ 
to use a pathname, segment number aaatoisiatiyle* memory. instead, 
find_ will always recurse to the ros*? whetu, resolving a» pathname. 
While this might see*. unattractive for efCieieney reason*; direct 
measurement of the impact of such* a scheme upon system 
performance reveals that system throughput would only be degraded 
by a small fraction, of a percent, ^n addition, our proposed 
address space manager will drastically reduce the number 6f 
pathname resolutions that ocour^. within the system. This 
reduction in pathname resolutions should render the difference 
between find_»s having and not having a pathname f associative 
memory almost immeasurable. This slight performance degradation 
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seems a small price fro p^Mmt timmMMiMsA^bti of the directory 
renaming problea outlined ate***; -' 

5.3 Compatlbllltv 

the final i topic He wish ttau>*l*tiift*s in ^his ehapter lis 
that of e^mp*fe|bilifey« A basic f^pei*aililftf'*af^iriy cdmputihg 
utility is to *inimij» fchs «ffeet^P"«»««*ill^''#lringe# n - ; uiJon its 
user community. If a major change »u«t bo made in the interfaces 

between : uss# <ir^t||a fm&^ema^'^ms^^kmmp^miif^p e f# "Hfie semantics 
of these ij*t*rfa^^iuvt : lis!i^ bbth th# ne^ 

and old interfaces for a sufficiently long period of time to 
allow . users ^to/oonsMM^ '-fel^ip;^ v$$g ".tug-; Sft%r irfterf aces . 
A suitable measure of this period :<*f Mae* would probably be 
measured in months • s ,ertn , ;e:*ssjt . yesfs^ ;;«©% hoars, days, or weeks. 

We have made substantial eh#&#§* to the ring zero 
interface and thus must address the c©*f>atibili%y issue. 
Fortunately f ifr is quits simple to '-pr*S*r*s eoipatibility without 
keeping the old find^ and name and addrisispaei managers . this 
is possible for two: reasohsa First, wSiiintiiuiati the old ring 
zero interface by interposing a riag if #ur proitdure between the 
caller of an ebaolebs ring zero ! if*$#rfada -and ©dr new ring zero 
interface. Second, it is possible to tsMrpo«#° such simulation 
procedures between the user ,•'«* ^ ^He ,:: «##' 1 rfh%^ ; zef'0 interfaces 
without rscoding #** even reoo«pili«^ a^^s^ip^otrama* 
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Consider how we would simulate the old interface to 
initiate. The outer ring interposing procedure would call the 
outer ring reference name manager to map the pathname directory 
specifier of the old interface ' intfc the se^ielit number required 
by the new interface. It would then call the new initiation 
primitive. If this returned a linfcV the outer ring interposing 
procedure would start over again. rf ' 

This simulation procedure would be difficult to 
implement if it were hot for the fact that^uitics now has an 
interposing procedure on all calls to ring iirb: this procedure 
is a ring four transfer vector that hormallyHi-arisfers the' call 
to the appropriate ring aero gate. (1) ThiS-transfer vector can 
be modified so as to call an appropriate interposing interface 
simulation procedure for the interfaces we have changed. 
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(1) This transfer vector, which < was liscus^eo* ±h a previous 
masters thesis by Janson [J1] has not yet been installed in the 
current Multics system. 
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We have coded a test impleJMHi£»tio*i> of the essential 
features of our design. This test implementation, which is based 
on Multics system 2M.2, was «ndei^N#«a fer fear major reasons » 
First, a working implementation el ow .ideas* serves as an 
existence proof of the basic claim of our thesis. Second, a 
working implementation helps us demonstrate the practicality of 
our design. Third, the aetual task; ©I" implementing our design 
helps insure that we have not neglected any important details in 
our design. Finally, a test implementation ©f our design helps 
us to quantify the impact of eur design upon the system. 

6.1 Plan 

We have indicated that our new design requires an 
extensive overhaul of ring zero. The pervasiveness of the 
modifications necessary to ring zero is largely a result of the 
removal of pathnames from ring zero. While the removal of 
pathnames from ring zero is essential to our design, it is a time 
consuming, straightforward, and intellectually unrewarding task. 

Instead of undertaking this drudgery, we have devised a 
scheme that allows the essential ideas of our design to be 
implemented while avoiding most of the uninteresting work. The 
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implementation we will describe does not affeot any code outside 

of ring zero, nor does it affect the syntax or semantics of the 

interface to ring zero. As a result of this feature, our test 

implementation provides the first step in an Orderly transition 

from the current Mai tics system to the systetf we have described. 

The implementation we will describe could ^ be immediately 

installed in the standard Hultios system Without siibstantially 
affecting users. 

What we elected to do wa« to implement our new 
initiation, termination, and name space management primitives 
inside ring aero. We then reimplemented, inside ring zero, the 
old initiation, termination, and name spaer management primitives 
using our new primitive*. This scheme allowed us to concentrate 
upon the key issues of our design without getting bogged down in 
the mechanics of converting thirty or more large complex programs 
from using pathnames to not using pathnames. 

The strength of this apprdach is that the modules in 
ring zero may be slowly jweaned away from using pathnames or now 
obsolete interfaces. Also, by supplying Agates to our new 
primitives, users of Multica can st^rt converting their programs 
to take advantage of the new ring zero interface^ When ring zero 
has been completely converted, all we* need do "is throw away the 
code that implemented the old primitives in liernftr of the new 
primitives and move the reference name manager out of ring zero. 
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6.2 Impact on System Complexity 

Reducing the cempleslty of a system certainly increases 
its oertif lability [Qr t &2, D3, M r *l, -»TJ. In order to 
substantiate the '..iiypotliesia that ^eafrvdestgnu results in a system 
that is more cert ifieble that© Multics system 2**2, we till look 
at two measures of the -cssmplextity @# fch* -mvmwity kernel s of the 
two systems. These measures are the difference in size of the 
old ring zero and our new riaf zero and the difference in the 
number and complexity of gates- into the «mt& r$ug isero «nd our new 
ring zero. 

Appendix.; g,, summarizes the size comparison data between 
the old. ring. , zero*, and; .- our ne« riag- zef-%v' ^ Jmv It reports, the 
address space manager was r#£««ed i»t:a€J*e^%y^s*^M%y-seven per' 
cent. This corresponds to a t#© and ahm4f per cent reduction in 
the size of ring zero. In fact, the address spies manager that 
we. designed was so small that we have presented it in appendix H 
for the reader to peruse. Ihle sizeable reduction in the size of 
the address apace manager is quite encoeregiag and Substantiates 
our claim that we have produetd a m^re scd-rtift*&le ring zero. 
What is. even more . en^e^af*a#4mfftfi»fc^Mi^Ji»l^e''i'thts 'figure is in ' 
itself substantial r .-it *■■•»*$ jrepresepta* **pan*ialV implementation. 
Several module* in ring/ze^ .aoeep^fc^fcte^ 

numbers as storage system c^Jeois *peoifiers. ! In a complete 
implementation of our design mmny cap these modules would only 
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accept segment numbers. This wojiid alJUaw tJi*.caa* that handled 
the pathnames in these modules to be thrown out of ring zero, 
further decreasing its complexity. 

The old ring zero support* aeoufc two hundred gatesv 
Our design dearly removes the necessity of having gates into 
ring zero whioh call the referenoe same manager^ -It also removes 
a whole class of gates that allow an objeot to be specified by 
pathname. Many gates into the old ring aero came in pairs, dhe 
gate would specify the target object by^Mgmeftt number. -The 
other gate would specify the target objeot by pathname. With the 
ability to initiate direafeories ;in tfc^ 

multiplicity of gate* becomes unnecessary ;u As a? result, only the 
gates that take a augment number <j*aw :ofc$gajfti' : sp^eKfif ie*» Uj would ^be 
retained in the ring zero of a eiOBpfcete iyp^ei&ntation of bur* 
design. When we add up the number of gatas that a full 1 
implementation of our design would remove from the current ring 
zero, interface, we find that we wowJafc raaovje «feout five per cent 
of the gates. Xn a4o\ition to reducing tknn number* i-«p -gates inttf 
ring zero, we hav« signifioantly simpliifaipd? fets© interface to over 
fifty of the ga tea that must jremain- in ^ing MEeroY { 1 ) This 
reduction in Interface complexity also 4*n4a credibility to out** 
claim that we : have mad* risg : ^^% I«mdaih«h6* ifaltics^ more 
certifiable,.,..- . ;i .. ■'>;,•,. - ? ,- '-m,/.:.' 1 '' ■:■•-: ■ 



(1) See appendix G. 
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6.3 Iflaafct an System Perfflrmanffi* 

To help assess the impaet ef tmt* design upon the 
performance of the Multics system, we developed a small benchmark 
that tests the speed and paging toriMWlor of tHe most used system 
functions that our design affedted. TMS benchmark was run on 
both Multics system 2**2 and o«r test 'Impiimehtat ion. The 
results of these runs indicated that the Virtual epu time to 
initiate and then terminate *n d6j#dt dipped from 11.002 
milliseconds in the standard system to f0»22f iilliaeeonds in our 
test system , a reduction of «ig*t pe* 1 ^^Ht. '(1) This is 
especially gratifying since the t#<t e«me space manager we 
implemented was not ia the -leautt o^*i#i^e^l%#ri«»niflg speed, in 
addition, our test iiBplepentafciow was '^wfUr^ply penalized by 
having to converse with our fe*««dhma«fc tliroug** a simulation of the 
old interfaces. 

We attribute this ape«d up to many f asters; not the 
least of which is the fact that we greatly simplified the 
structure of the known, segment table, we als% make the somewhat 
immodest claim that our initiation, termination, and reference 
name management primitives were slm^ijr *N*de# better than those in 
system 24.2. But this is not surprising* met* things are done 
better the second time around. It should also be noted that the 



(t) A description of Our benchmark as well as a brief summary of 
the performance data can be found in appendix F. 
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smaller and less complex a module is, the easier it is to program 
that module efficiently and correctly. Unless a programmer can 
hold all of the relevent details and specifications of a program 
in his head at one time, it is very difficult to perform global 
optimizations or simplifications of the program. 

Our working set performance data indicates that our 
system referenced two more pages running the benchmark than 
system 24.2. This did not come as much of a surprise. One of 
these extra page faults resulted from splitting the code of the 
reference name manager and address space manager apart and the 
other resulted from splitting apart their shared data base. We 
anticipate that when programs are converted to use the new 
interfaces directly the extra page fault that was caused by 
splitting the code apart will be compensated for. We expect that 
since our code is smaller in total, by eliminating the simulation 
code we will decrease the working set by a least a page. This 
will make up for the extra page fault caused by splitting the 
reference name manager and address space manager apart. The 
increase in working set due to splitting apart the known segment 
table cannot in itself be avoided. However, this increase in 
working set is only on the order of a half of a page and is 
independent of the combined size of the new data bases. 
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We have not really put mueh effort into the performance 
arguments above. We feel that the performance data which we have 
reported above is sot, in fact, a good .■ measure of the performance 
of a full implementation of our design. We claim that there is a 
hidden performance factor which will easily swamp out the 
performance effects we have been discussing. Fortunately, this 
hidden performance factor is In oar favor, the effect to which 
we are alluding will not be seen immediately but will slowly 
assert itself. This effect has t© do with the gradual conversion 
of major supervisor and user programs to use segment numbers as 
directory specifiers* Since pathname resolution is fairly 
expensive (even when flnd^ is gi^en a pathname «- segment number 
associative memory), the use of segment niia^irs as directory 
specifiers will save an average prooe«s a «l^>s*«titial amount oT 
computation. 
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Chapter frit 
Conclusion 

We have argued that reference name management need not 
be supported by the security kernel of a computing utility. In 
particular, we have demonstrated a transformation oh the Multics 
system that removes reference name management from its security 
kernel. Our design has further simplified -the Multics security 
kernel by allowing directories teTb* initiated 'outside of ring 
zero, and removing the ecnoept of a storage system link from ring 
zero. In the process, we have repaired an inherent security flaw 
in the current Multics design that allowed processes to detect 
the existence of objects in the storage system hierarchy to which 
they had no aocess. This flaw resisted frtfm having insufficient 
access control on links and from ring zeroes failure to terminate 
undetectable directories. Finally, we have provided a solution 
to the problem of clearing find_'s pathname associative memory 
when a directory is renamed. 

We have used a technique in our redesign of the Multics 
system that we feel deserves special^ mention. This technique 
involves constructing a careful lie to maintain the security of a 
piece of data. In our case, we constructed a Security kernel 
that lies ateout the existence of a directory until the caller 
proves its right to know of the existence of the directory. This 
lie, which was actually quite easy to maintain, prevents a 
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process from detecting directories that should be undetectable by 
pretending that all possible pa?thna«$fs correspond to an existing 
directory unless the process has sufficient access to the object 
specified by the pathname tx> |*roye oth#«*vi®ev 

We have implemented and tested* Mm key points of our 
design. This implementation has shown that our design is both 
simpler and more efficient than Multisa 2*. 2* More details of 
our design than were presented in the body of the thesis may be 
found in the appendices that follow. In, -particular ^ appendix H 
presents the actual programs of the *ddre*s space manager 
designed in this thesis. 

In conclusion, we would lijte to noite three observations 
we made while designing a new .address space manager for Multics. 
First, our address apace manager, whi£h ism tmr simpler than the 
current Multics address space manager , aLa© is more efficient 
than the current address space manager-, i fh* complexity of the 
current address space manager cost Multics both space and 
performance. (One is tempted to believe that, in general, 
complexity added to improve performance is frequently 
counterproductive.) Second, because Multics is an existing 
system, the functionality and use patterns of the Multics address 
space manager were thoroughly understood ukem we fcegan our 
research. A large part of the simplification achieved is the 
direct result of insight extracted by observing the existing 
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implementation of these mechanisms. Finally, we noticed an 
impressive threshold effect. As our design progressed it got 
simpler and simpler. At a certain point, when our design was 
simple enough so that all of the relevant details of the design 
could be considered simultaneously, our design underwent a 
further drastic simplification. This simplification was only 
discovered when the mechanism became simple enough and small 
enough to be kept in the head of one designer all at one time. 
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AMEMhZTL * 

The »&ijj dfcfca base fit tb« Hultie* system 2*».2 ring 
zero address and reference name manager is the &nown Segment 
Xable. Th# 1S1 i»^ a jwr*pw^*s* r M*gtSNt#© -§#§»#« t. Logically 
it contains three items. First, it contains an array of KST 
Entries. KSTEs are indexed by segment number and contain all 
per-process information necessary for the proper care and feeding 
of the segment or directory associated with the indexing segment 
number. Second, it contains a hash coded mapping from the space 
of Unique Identifiers onto the space of segment numbers, or 
equivalently the space of KSTEs. This mapping provides the means 
of locating the KSTE of an already initiated segment should it 
subsequently be initiated by a different name. Third, it 
contains a hash eotfetf mapping from the space of names onto the 
space of segment numbers. This association is mainly of use to 
the dynamic linking mechamismv The current contents of a KSTE 
and their major usages are given in the following table. 
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KSTE Field 

forward pointer, 
backward pointer 



unique identifier 



name pointer 



inferior count 



'parent segment number 



entry offset 



directory switch 



Use 



These pointers are used to chain 
the fCS^E tffltb a li#t? of free JtSTES 
when it is not in use. 

The unique identifier of the 
segment is vim& to validate UID 
hash searches and to properly 
identify the corresponding 
directory entry after an on-line 
salvage. 

This pointer chains together a list 
of the reference names associated 
with « this segment or directory. 
Stored with each reference name is 
to* hutaber of the ring irr which the 
nam** '* known. 

The inferior count records the 
number of inferiors of a directory 
that are in the process* address 
space. This information is used to 
prevent a directory from being 
terminated while it has known sons. 

This entry records the segment 
number of this segment's parent. 
It is Used at segment fault time to 
help locate this segment's 
directory entry. It also is used 
to translate sigaefht lumbers into 
pathnames. 

This entry, which records the 
offset of this segment's directory 
entry within its parent, is used in 
conjuction with parent segment 
number to locate the segment's 
directory entry. 

This flag, which is set to indicate 
that the segment implements a 
directory object, is used to 
special case access setting for 
directories at segment fault time. 
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APESMfilS B 
Structure of the Proposed Known Segment Table 

Our redesigned KS-T has been simplified and contains only two 
components: a KSTE array > and a UID hash table. The contents of 
each KSTE and their 'mm&or uses are summarized below. 



KSTE field 






forward pointer, 
backward pointer 



unique identifier 

inferior count 
entry pointer 

directory switch 
rings 

highest detectable ring 



Used to thread KSTE onto free 
hash Glass list as required. 



or 



Uftehaaged (a phoney directory will 
have a uid a 0) . 

Unchanged. 

A pointer to the directory entry 
for this segment . 

Unchanged. 

An eight bit field containing one 
bit par ring. Whenever ring i has 
this segment number initiated then 
bit i of this field is on. 

A number that specifies the highest 
ring in which this process has 
established its right to know of 
the extstenoe of this directory. 



-96- 



«is?H^*^**^*^w^*ww>*««s;j^ 



APFEHPIX C 
Proposed Address Sgao* Manager Interface 



The proposed ring zero address space manager interface is as 
follows. r 



initiate_ (dir3egno,ename,dirsw,link", segno, code) 

dirsegno segment number of the parent (input) 

©name entry name of target (input) 

dirsw directory switch (input) 

link link (output) 

segno segment number of target (output) 

code status code ^output) 

possible status code values: 

error_table_$segknown - : — segment already known to process 
error_table_$invalidsegrto — - parent is not a directory 
error_table_$noinfo — -insufficient access to return any 

information 

error__table__$nrmkst no more room in known segment table 

error_table_$no_entry ■ ---i. entry does not exist 

error_table_$wrong_type entry is of the wrong type 

error_table_$link — - entry is a link 

terrainate_( segno, code) 



i 



segno segment number to be terminated( input) 
code see Above 

possible status code values: 

error_table_$invalidsegno segment number is not bound to 

an object 
error_table_$infcnt_non_zero can't terminate due to 

active inferiors 
error_table_$known_in_other_rings can't terminate due to 

segment number being used in other 

rings 
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To help clarify the Wea» presented in this thesis, 
let us consider the following scenario in which a process tries 
to initiate the segment >a>b>c>d>e>f in ring four. We will 
assume that directory e and augment, f do Mt exist and that the 
process has no access to a, b or d, and append permission to c in 
rings zero through four. We hsve presented below 
representation of this path through the hierarchy along with the 
process 1 access rights to each object in ping four. 

"root" < — status 



a 



a < — null 



b <-- null 



c < — append 
d <— null 

To simplify matters we will ignore the existence of the outer 
ring reference name manager and we will assume that we are 
operating in a virgin environment. What follows is how the- outer 
ring find_ would proceed in this case. 
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step call lnitiate_(0,"^, f, link, segno^of.root, code) 

The root directory* will be i ' ■'Initiated, its detectable 
field in the KSTE will be set to four, and a status 
oode of zero will be returned, (all processes have 

step 1 call '■ 

itiitiate_(3egnb_of_root , "a" , 1 , link ', segho_of_a , code ) 

The directory will be initiated, its detectable field 
in the K?TE will he a^t to four, mixl, a^taAua code of 
zero Will be returned'. 

step 2 11 initiate_tsegno_of_a, k b» , 1 , link ,segno__of> , code) 

The direotory will be initiated , its detectable field 
in the KSTE will be set fester©, an* the, status eode 
noinfo will be returned. 

step 3 11 initiate_(segno_of_b f "c w ,1,iink > segno - of_c,code) 

The directory will be initiated, its detectable field 
*!?, J ne * S ?P *Ml be set to four t and a zero status code 
will be returned. In addition this Initiation 
establishes the prooeas' ,r4fM^tQ^now,©f tlie existence 
of superior directories at least in rings zero through 

£°i! r * . I? 1 * J" 3 r * f ^ e ?^* d f Mhl*i#ii?aw, by setting t®* 
detectable field in the KSTE of >a>b to four. 

step J* call initiate_(8egho - of_c,"d",r,link,segno.of_d,co 

The directory d will be initiated, its detectable field 
in the KSTE wil V k? set to fc^irv a^d, # »*ro status code 
will he returned.* 

step 5 call initiate_<segho_of_d,»e", 1, link, segno_of_e, code) 

The non existent directory e will be assigned a KSTE 
which will be marked as phoney and the status code 
noinfo will be returned. 

step 6 call in it iate__(aegno_of__e,"f" ,0, link, segno_of_f, code) 

No KSTE will be assigned and the status code noinfo 
will be returned. 

step 7 call terminate_(segno._of_e,oode) 

The segment number assigned to e will be released on 
the grounds that e may not really exist. 
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APPENDIX q 

Size of Prw-rw 

In this appendix we summarize comparison data between 
the size of the Mult lea system 24.2 security kernel and the size 
of our proposed Mul tics security kernel. We have only included 
data for the tm^mr progress that were affected by our design. As 
a basic measure of the size of a procedure we have chosen the 
number of words of text in its Multics object code module. This 
corresponds roughly to the liamteer of machine Instructions in the 
module. We notice that in most cases the procedures in our 
system are markedly smaller then their counterparts in system 
24.2. Our reduction of the security kernel by 3345 words or 
about two and a half per cent may not appear spectacular, but the 
reduction in size of the address space manager is seventy-seven 
per cent. This has substantially reduced the complexity of the 
security kernel. The reason we can make this claim is that while 
the reference name manager in system 24.2 is not that large, it 
is complex far out of proportion to its size. 
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old procedure size 



new procedure 



find_ 


791 


128 


f ind_entry 


makeknown 


732 


164 


makeknown_ 


kstsrch 


440 


103 


kstsrch 


kst_man 


45 


34 


get_kstep 


makeunknown 


1044 


123 


terminate_ 


initialize_kst 


667 


82 


initialize_kst 


initiate 


698 


288 


initiate_ 


kst_entry_check 


1 12 


88 


kste_info 






84 


kste 






86 


validate_segno 



4529 1184 
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perfgnance Pfta 

In order to measure the change in overall performance 
between our system and Multics system 24.2, we developed a 
special benchmark program. This benchmark was designed to 
evaluate only the acst commonly used features that we modified in 
our design: segment initiation, reference name management, and 
segment termination. Specifically, our benchmark called the old 
ring zero initiation interface ( 1 ) to initiate a segment and give 
it a reference name. It then used the terminate by segment 
number primitive of the old interface to terminate the segment 
and unbind the reference name. This was repeated one hundred 
times. The virtual opu time in microseconds to complete the 
benchmark was then divided by one hundred to obtain a normalized 
performance timing datum. The total number of page faults for 
the run was also recorded. 

The benchmarks for both systems were run on December 
10, 1974 within ten minutes of each other on a dedicated 
computer. The standard Multics system used was designated as 
Multics system 24.2. Our test system was identical to system 
24.2 except as it implemented our design. Three runs were made 
on each system. The first run served only to cause dynamic 
linking to occur and to bring the pages that our benchmark 



(1) The old ring zero interfaces were simulated in our system. 
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touches into primary memory. ThM**Afend run, which took no page 
faults, was used to. obtain our\ tUdLafc . da£a4 ; (45 Multics system 
24.2 averaged 11002 microseconds for each iteration of our 
benchmark. Our test implementation was aetuilly seven per cent 
faster, taking 10226 microseconds per infeerafcion. the final run 
was made after the contents of primary memory were ? f lushed. This 
run established .the siie of the working swt of our benchmark 
since each page touched while running our : ben6nteark produced a 
missing page fault. The working set of our benchmark in Multics 
24.2 was five pages. Our. te«t implea»»*a^i<in had a working set 
of seven pages. 



(1) Prior testing had shown that multiple runs of the benchmark, 
under identical conditions, produced times within one hundredth 
of one per cent of each other. As a result one timing run was 
all that was required. 
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This appendix lists briefly the changes we have made 
in the ring zero interface of Multioa systea 24.2. We have 
excluded from this appendix the changes we have made to the ring 
zero address space manager interface as these changes have been 
documented in appendix C. 

hos_$chname_file 

hcs_ifs_get~path_name 

hos_$d«l«ntry_jrile 

he s_$ f s^ge t^ref^naoe 

hcs_$fs_get_seg_ptr 

hcs_$status w »inf 

hcs_$terainate..file 

hcs_$terminate_nane 

hcs^iteroinate^nonajie 

hcs_$truncate__fiie 

hcs_$set — bo 
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WfrrfftCfig G«lYftl&e4 TO Sg»Q#fyifHr Tfrair Tar g et Obleot 

By Directory gatimairiy 4*»£ fentfv Nam* 

hcs_$add_ael^enti*:ie3 

hca_$add_ldir3aoi^ehtrie$ 

hoa_$add_dir_iaol^entri^$ 

hoa^add^iadllefitpip- 

hc3_$del_dir_trW" -' ; '* 

hcs_$delete^Ibij_entri<ia 

hc8_$deJtete_dir_aiii^,e0^^s 

hca^dele^^di^ff^^^s 

h c s__$ d e 1 e t e ~f tf ele_w ff fcf iek , 

hcs_$g J e\j*AkK6V Ish " ;rT; ■ rtW " 

hca_$get_bc_author 

hcs__$get_dir_ringjt>rackets 

hcs^get.jnax^length 

hoa_$get_ring_braoketa 

hcs_$get_safety_aw 

hc3_iget_user_effmode 

hcs_$liat__acl"" 

hca_iliat_dir acl 

hcs_$list_dir_iacl 

hc3_$li8t_inacl 

hcs_$quota__move 

hoa_$replace_aol 

hca^ireplaceZdir^acl 

hca_$replaee_di*v.inacl 

hca - .$repXaoe_inacl 

hcs_$set_copysw 

hcs_$set~dir_ring_bracket3 

hca_$aet_max_length 

hcs_$3tatus__ 

hcs__$status_ long 

hphcs_$add_acl_entries 

hphcs_$add_dir_acl_entries 

hphcs_$delete_acl_entrie8 

hphcs_$delete~dir~acl__entries 

hphcs_$replace_acl ~~ 

hphes_$replaee_dir_acl 

hphcs_$set_act 

hphcs_iset_auth 

hphcs_$set_bc_auth 

hphcs_$3et_dates 

hphcs_$set_dlr_ring_bracket8 

hphcs__$set_ring_brackets 

hphcs_$status_baokup_info 
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Interfaces CffinYttrUd TO &BM&J£mLna. IfafriP Target Object 

By Elr# fffrftrr Pftftfmaftt 

he s_$a ppen4_b ranch 

fee #jMPf#»4jto*a*fe* : 
h c 9.f appeacj^llok 

hcs_istap» 

hca^istair^list^ 

hphcs^lquota^reload 

hphQs^taalvage^dir 
hpftes^fstjar^ncyaoc^eii 
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APPENDIX H 
The Addreas Sbaoe Mfrnafrer Pr^fr^ 

We have *slaimied that th* address Space manager we 
designed is simple, small and easy to certify. : To substantiate 
this claim, we are including in this appendix the source code of 
our address space manager for the reader's perusal. These 
programs differ from the actual programs that ran in our trial 
Multics system only in a few minor details. (1) 

We will divide this appendix into three sections. The 
first section contains a declaration for the KST. This 
declaration is used by programs that contain a "^Include kst;" 
statement. The second section contains the PL/I source programs 
that constitute the address space manager. Finally, the third 
section describes the calling sequence and functionality of 
system modules called by the programs presented in section two. 

The baseno and ptr PL/I builtin functions used in the 
programs in this appendix are non-standard PL/I functions used in 
Multics to manipulate pointers. A Multics pointer may be viewed 
as a pair of integer values. The first component of a pointer is 
interpreted as a segment number by the Multics hardware. The 
second component of a pointer is interpreted as a word offset 
within the segment specified by the first component. The baseno 



(1) See appendix I. 
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builtin function constructs a pointer to the first word in a 
segment given a segment number for that segment. The ptr builtin 
function constructs a pointer from the segment number in its 
first argument, which must be a pointer, and the integer offset 
which is its second argument. 
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— -> get_branch_info 

This file system routine is called by initiate_ to get 
the attributes of a named entry in a directory. If the caller 
has no access to the named object (if it exists) or to the parent 
directory then the status code error_ta4>le_$jioinfo is returned. 
The reader should note that get_branoh_info must read the access 
control list of the directory containing the named entry if the 
entry does not exist or if the process has no access to the 
entry. To locate the access control list of the containing 
directory, get__branch_info must call the kstejlnf© module of the 
address space manager, a recursive invocation of the address 
space manager. 

Usage: call get_branch_info (psegno, ename, type, uid, ep, link, 
code) ; 

psegno fixed bin (17) -*•- directory segment number (input) 

ename char (32) aligned name of entry iiv directory (input) 

type fixed bin (17) — - type, of the object (eutput) 

-- no entry 

1 — segment 

2 — directory 

3 — link 

uid bit (36) aligned — - unique identifier of object (output) 
ep pointer — ■- pointer to the entry of the t>f>jtect (output) 
link char (*> varying --- contents of the l^k( output) 
code fixed bin (35) --- error code (output) 
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> thread$in 

This routine adds an element to a two way linked list 
of elements. The first word of eafch element contains the 
necessary forward and backward pointer*. 

Usage: call thread$in (where, what); 

where pointer pointer to an element in the list after which 

the new element is to be threaded, 
what pointer — pointer to the element to be threaded into 

the list. 



> thread$out 

This routine threads an element out of a two way linked 
list built by thread|in. 

Usage: call thread$out (what); 

what pointer pointer to the element to be threaded out of 

the list. 

- — > level$get 

This routine returns the validation level of the 
calling procedure. In all cases considered in this thesis the 
validation level of a process is equal to the number of the ring 
in which the process was executing when it called into ring zero. 

Usage: ring = level$get (); 

ring fixed bin (3) validation level of the process. 
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> disconnect 

This routine physically removes a segment number from a 
process' address space by zeroing the segment descriptor word for 
that segment number in the process' virtual address translation 
table. 

Usage: call disconnect (segno); 

segno fixed bin (17) segment number to be disconnected. 
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APPENDIX I 
UnifflPleffiented- Address Soaoe Manager ruination a 

In our discussion of the Multics address space manager 
we omitted three mechanisms that it currently supports. These 
mechanisms, which are non-essential to our design, were omitted 
to simplify our presentation and avoid confusion. In this 
appendix we will briefly describe these mechanisms and show how 
they fit into our design. 

1.1 Reserved Switch 

The Multics initiation and termination primitives take 
a reserved switch argument. In the case of initiation, this 
switch specifies, if set, that the caller Irishes to specify what 
segment number to bind to the object when it is initiated. 
Naturally, ring zero must check that the oelter has in fact 
reserved the segment numoer. When the ring zero initiation 
primitive is called without the reserved switch set, then ring 
zero chooses a segment number from a list it maintains of free 
segment numbers. This segment number is bouncfe to the object and 
returned to the caller. In the case, of termination, the reserved 
switch specifies whether the freed segment number is to be 
eligible for assignment wlien a free segment number is needed. 
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The reserved switch must clearly remain a protected 
security kernel mechanism in our new address space manager. Were 
this not the case, one protection domain could cause another 
protection domain to malfunction by using a segment number that 
the first protection domain had reserved. 

1.2 Cffigy SwUffito 

During the process of initiating a segment, an 
attribute in its directory entry called a copy switch is 
examined. If the segment has the copy attribute, then a copy of 
the segment is made and this copy is made accessible to the 
process instead of the original. 

We can use the mechanism of reflecting information out 
to an outer ring by setting a status code to remove copy switch 
processing from ring zero. This is possible since the current 
initiation primitive takes an argument that allows a process to 
bypass copy switch processing. Together with the fact that no 
ring zero procedures or data bases have their copy switch set, 
this insures that the protection mechanisms of the system do not 
depend upon the segment eopy on initiation facility. To take 
advantage of this, our new initiate primitive will not process 
the copy switch. Instead, It will always initiate the target 
segment and return a status flag indicating whether or not the 
segment's copy switch was set. The outer rings can then worry 
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about creating a copy of the segaettfc, terminating the original, 
and returning the segment number of the copy if the copy switch 
was set. This allows the concept of a odpy switch to move out of 
ring zero. 

1-3 Transparency Switches 

When a segment is initiated in the current Multics 
system, the address space manager sets two switches, called the 
transparent usage switch and the transparent modification switch, 
in its KSTE. These switches determine whether this process' 
usa&e and modification of the Segment is to be detectable to 
other processes in the system. These transparency switches have 
no influence upon our design except %&m in an i»ple»e»tat ion of 
our design (as in our test implementation) these switches would 
be kept in the KSTE of a segment and the address space manager 
would retain the two lines of code from the ©i*rrent address space 
manager that sets these switches. 
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